IMO, the iso_varying_string should drop the iso prefix until it actually becomes part of the standard.
The aim of stdlib is to become a de facto standard. In the past I have remarked that it would be nice if vendors showed interest of packaging it in their compiler distributions, but so far I’ve seen almost no sign of interest.
I believe @certik has previously suggested making the stdlib modules part of LFortran, but this would not make them part of the Fortran specification. Quoting section 14.2.1 of J3/18-007r1
A module that is provided as an inherent part of the processor is an intrinsic module. A nonintrinsic module is defined by a module program unit or a means other than Fortran.
Procedures and types defined in an intrinsic module are not themselves intrinsic.
I haven’t used the varying_string module to be able to judge fully, but I understand the main differences is it provides put and get procedures, which we rejected in stdlib in favor of derived-type I/O, and it provides an additional assignment operator from varying_string to character, whereas in stdlib we opted for an explicit conversion using a function named char. (@everythingfunctional, please correct me if I’m wrong.)
Were the string_type to ever become standard (either as an intrinsic type, or a modified varying_string proposal) I believe we could deprecate the stdlib one and amend our documentation to suggest using the one that is part of the standard. But in principle it would remain viable forever as it’s just a non-intrinsic user derived type.