CoreCLR does have the ability to compile the GC as a DLL and then choose different GCs are runtime by loading different DLLs. Search for FEATURE_STANDALONE_GC in the code base.

This feature is enabled in the official builds though.

You meant "local GC" initiative?

Ain't that relatively young, not so mature and and designed with specific GC design in mind interface?

It is. A few key assumptions are based into the runtime, namely that the GC is a generational GC with contiguous regions and that the GC doesn't need a read barrier, among many other things. There's a bunch of assembly in the runtime that embeds some implementation details of the GC in a way that's hard to decouple. The API came about by untangling the GC and the rest of the runtime; it took a lot of work and the resulting API probably isn't what we'd choose if we were building a GC with it in mind from day 1, but the whole scheme of sideloading a GC works pretty well.

You may be interested in watching my talk about it at NDC - https://www.youtube.com/watch?v=zVbTmgbiZsA&t=23s