Could you please add short FORD comment blocks for theese APIs? As an example:

If the documentation is added here, it should be placed following the interface declaration or within the function declaration if there is no additional interface, and not before the public statement as it is done within this module currently. I actually have issues with FORD locally to produce the documentation because of that but haven't mention it yet to avoid mixing issues within the same PR.

Yes, it is a good idea to address (these and perhaps more of) FORD issues in a separate PR. For the current PR, I think it's ok to stay consistent with the current syntax.

I have added the docs following the interface blocks of these interfaces... Isn't that enough?

Because stdlib offers a string type, it would be nice if these string manipulation functions were interfaces working with either character strings (as currently proposed), or the internal string_type type.

I made these functions interfaces keeping this possibility in mind... But what is considered a good way of doing this? Writing procedures for string_type and then, when calling them with character variables just assign these to the new string_type variables and call the string_type version of the interface itself or code duplication, keeping the code separate for these two although they are in essence the same?

Ah, I got it!

Yes: the easiest option is to keep the character implementation and then return the result to a string via move:

I have added the relevant changes... But it doesn't use move, it uses assignment(=) and char, Let me know what you think of it.

It works @wassup05, however, there are two copies: string->char for the input arguments, and then char -> string on the assignment. Using move would at least avoid incurring the last copy. Just do:

character(:), allocatable :: join_char
join_char = join_path(char(a),char(b))
call move(from=join_char,to=...result variable...)

Because the internal string_type representation is just an allocatable character variable, I would also support (to be discussed with the community as a separate PR) the implementation of a tiny zero-copy "view" function for the string type, see here:

 !> Zero-copy view of the string as a character array
 pure function view(string) result(char_array)
 type(string_type), intent(in), target :: string
 character(:), pointer :: char_array
 if (allocated(string%raw)) then
 char_array => string%raw
 else
 nullify(char_array)
 end if
 end function view