My use case is to add a custom built-in model generator (specifically for generating pyramid block shapes not supported by vanilla model definition files) just like vanilla's minecraft:builtin/generated that is then used as a parent in actual model definition files.

My model works exactly as ItemModelGenerator does, nothing has to be loaded from any file and the model does not need to be baked separately or anything like that.

In 1.21.4 it was possible to emulate the described functionality as the null model encountered during model resolving would be passed through the unbaked model loading event and could be replaced there. In 1.21.5 that is no longer the case as the unbaked model loading event no longer seems to run during model resolving and therefore misses out on these null models.

All I really want is access to the ModelDiscovery instance so that I can call ModelDiscovery::addSpecialModel or an option to manually put unbaked models in Map<ResourceLocation, UnbakedModel> passed to ModelDiscovery again as in 1.21.4.

The extra models API is currently missing due to large vanilla changes in 1.21.5 and is planned to be re-added soon, but could this use case not be covered with the UnbakedModelDeserializer?

Ah yes, that'll work. XFactHD also had the idea to simply provide an empty json file and replace that model via the unbaked model loading event.

Would still prefer to be able to use ModelDiscovery::addSpecialModel or an alternative as described above fully in-code.

I just reread the issue description and it is intentional that "model resolver" functionality (formerly ModelResolver since the start of the API and a null model in OnLoad in 1.21.4) is no longer available in code. A custom deserializer is supposed to be used for such cases now. Even when the extra models API is re-added, it was not planned that model resolver functionality would be re-added.

Is there a specific reason why you don't want to use a custom deserializer?

That's ok, I think the alternatives (empty json file / simple mixin) work well enough.

I'm using a multi-loader setup and all my data-gen has always been done on NeoForge. Having to include mod loader specific data like the fabric:type property and I guess something similar for NeoForge once their model api is reworked is simply an inconvenience.

NeoForge and even Forge have had an equivalent that works exactly the same way since a very long time ago. It doesn't use the same key, but you can simply include both in your file.