Coexistence of GSL implementations

The Core Guidelines make clear that Microsoft's GSL is but one implementation of the GSL:

FAQ.51: Is github.com/Microsoft/GSL the GSL?

No. That is just a first implementation contributed by Microsoft. Other implementations by other vendors are encouraged, as are forks of and contributions to that implementation. As of this writing one week into the public project, at least one GPLv3 open-source implementation already exists. We plan to produce a WG21-style interface specification to ensure that different implementations agree.

Existing implementations of the GSL do diverge in some details which are underspecified or seem questionable, so a precise interface specification would help. However, this doesn't address the question how different GSL implementations can coexist. This becomes a problem when using the GSL in library code; my function may accept a parameter of type gsl::span<>, but what if I use a different GSL than my caller?

I'd appreciate if the Core Guidelines editors could take up a stance on this. E.g.:

• Different GSL implementations cannot be expected to coexist. This would raise the follow-up question if the GSL should be used at all in libraries.
• The GSL is header-only, so we're fine if every translation unit uses only one of the implementations. This could still lead to link-time issues because there can be two distinct types called gsl::span<> in the same target.
• Every GSL implementation should use a dedicated namespace (e.g. ms_gsl, gsl_lite) and corresponding macro prefixes (ms_gsl_Expects(), gsl_lite_Expects()); it could still offer a convenience header which says namespace gsl = ms_gsl and which would be incompatible with the convenience header of competing implementations, but at least we get no link-time ambiguity.