MehVahdJukaar/Supplementaries#465

Context:

Hm, I'm investigating this issue, and oh dear god, it goes deeper than I thought;

The developer is right, there is a divergence between QSL and Fabric API on here, but the actual difference is that Fabric API doesn't care if you feed it invalid values, which can happen if you attempt to add an unregistered entry (block, item, etc.) to a content registry, while QSL, due to how it's content registries are based on the Registry Entry Attachment API (which is data-driven), needs those to be valid on adding them or else it'll not be added properly;

The true solution here is to always make sure that the relevant content is added to the content registries only after they're registered; I don't know how the workaround was done (it's source code wasn't published), but if it does follow that? I'd advise to keep it;
However, since this issue is pretty common on the Fabric ecosystem, an workaround for these cases was needed on our side, and therefore, on the Quilted Fabric API bridge, there is a deferred queue system that delays those bad content registry additions to after the relevant entries are registered, making them work, although with a theoretical performance hit due to it needing to go through all future additions to the Minecraft registry.

The real issue here? Somehow, the mod, with it's registry queue system plus the bad content registry addition, manages to pass Quilted FAPI's "is this registered?" checks and therefore goes straight to QSL's relevant Block Content Registry registry attachment instead of QFAPI's deferred queue, which causes the REA system to crash and burn since the checks on the FAPI bridge's side had a false positive and because QSL is stricter on this in order to avoid issues (although even that thing had managed to dodge QSL's own strict checks too! it was Guava's table implementation who caught the null!)

So, yeah, I will consider digging further on this rabbit hole and maybe fix this, but considering that Complementary was really the only case of this specific error ever happening? A fix might not be necessary (although i do hope that the workaround is indeed what i'm expecting), although yeah, this might point to a lack of checks that may be important later on, so I'll need to look deeper into this; Yeah, this is quite an interesting issue

work around has been made for supplementaries