If machine code is generated on (or close to) deployment, the implementation can choose a suitable collector. Hopefully, the proposed protocol will not require that implementations somehow optimize away interior object pointers for languages like Java that do not really need them, but make that obvious directly from the opcodes being used (or some other easily observed property). Likewise for the requirement to support pointer tagging for fixnums. Then the implementation can choose the appropriate collector based on what is being compiled (and the most general one for inter-language unification).
Keep in mind that typical builds of Hotspot support four or five garbage collectors, and most of them with two different pointer sizes. The required read and write barriers differ widely between collectors and in some cases even collector modes.
I'm not saying that it's going to be easy (an incredible amount of effort went into Hotspot over the years). But it's definitely possible to support wildly different GC strategies efficiently with sufficiently late code generation.
Keep in mind that typical builds of Hotspot support four or five garbage collectors, and most of them with two different pointer sizes. The required read and write barriers differ widely between collectors and in some cases even collector modes.
I'm not saying that it's going to be easy (an incredible amount of effort went into Hotspot over the years). But it's definitely possible to support wildly different GC strategies efficiently with sufficiently late code generation.