This proposal is to allow users of GSL to migrate their code to use import std; which at the moment is very hard, almost impossible, without using a lot of tricks. I believe there is a growing desire to port code to using the standard library module. However at present projects that rely on third party libraries find this impossible.

About this proposal

1. Any existing users should see no change, they have to opt in by defining GSL_BUILD_USING_STD_MODULE or equivalent macro
2. It does not assume anything about how consumers are building their code, it does not require them to use CMake or a package manager. It does not propose allowing the GSL project, including tests, itself to be build using import std;, I would be happy to do this work if people wanted
3. It is not a proposal to create a GSL module.

Currently the header files of GSL include headers from the standard library, for instance

#include <vector>

If a user I want to migrate my code to use import std; they can get compiler failures or at the very least a polluted global namespace when I also include the current GSL headers.

In effect we end up with the following

    import std; // User code
    #include <vector> // Via #include of a GSL header

I believe that doesn't compile on any compiler as of today and have been told it is very difficult to do for "reasons". So how about

    #include <vector> // Via #include of a GSL header
    import std; // User code

Well that does compile, mostly, but it throws away the main reason for modules, which is interface encapsulation. So on MSVC the following will compile, similar stuff happens for other compilers and standard libraries

    #include <vector>
    import std;
    std::_Iterator_base x;  // Magic internal symbol that leaks

So all the internal symbols and macros of the standard library will still pollute any user. You are also paying the compile costs of both the #include and the import std;. In general from experience in a more complex code base using multiple third party libraries it is extremely difficult to avoid arbitrary ordering of #include and import std; Even if compilers do manage to allow arbitrary mixing of #include and import doing so, I believe will still be fragile and poor practice.
Note there are a few cases where you do need to include a header, so

#include <version>   // For feature test macros
#include <stddef.h> // For offsetof
import std;

Generally this is most to access things only available as macros or C functions not in the standard library. For more info see https://wg21.link/p2654

So the proposal in the issue is to macro guard all #include of the standard library in the GSL public headers. For instance

#if defined(GSL_BUILD_USING_STD_MODULE)
    import std;
#else
    #include <string>
#endif

Note the macro name can be anything I just picked this as an example.
Also note there is an import std;. This is to make sure the headers can stand alone. It's not actually required as the users could always do a import std; before the #include of the GSL header as all exported standard library names would then be visible, with the exception of macros. This would look like

#if !defined(GSL_DONT_INCLUDE_STANDARD_LIBRARY_HEADERS)
    #include <string>
#endif