Honest question: what’s the alternative to inner-platform-effecting if you still want a system that’s highly user-customizable at runtime?

well, just have a proper code-based API?

not even separate textures are necessary, you could very well use atlases and just stitch them together at runtime with rectpacking and just remap the input texcoords to the new, bigger atlas... boom, mod support with atlases without creating 400 2KB .png's in the game folder.

similarly, blocks can be done in code, and modders can either use that, and optionally you can expose the same API in LUA or whatever if you need a less involved / sandboxed version of mods which can be downloaded from a server or whatever.

Here's an example of shit being done from code, it's fairly terse and you don't need to trawl through 7 files to do anything: (yes I know it doesn't have i18n yet but that won't make it much more complex either)

    SHORT_GRASS = register(new Flower(Blocks.SHORT_GRASS, "Short Grass"));
    SHORT_GRASS.setTex(crossUVs(8, 1));
    SHORT_GRASS.setModel(BlockModel.makeGrass(SHORT_GRASS));
    SHORT_GRASS.transparency();
    SHORT_GRASS.shortGrassAABB();
    SHORT_GRASS.noCollision();
    SHORT_GRASS.waterTransparent();

For data files (textures, sounds and other assets) you could use a virtual filesystem like Quake did (PhysFS is a good library which vaguely approximates that) and get rid of the stupid amount of folder nesting specifying behaviour, you can just have toplevel folders and use modloader order to disambiguate.

tl;dr: almost anything can be made to work with the most convenient/most sensible method of making stuff instead of using a bunch of awkward and convoluted JSON files you aren't even using! (MC internally generates the JSONs from code, so the data lives through a code -> JSON -> code roundtrip, they aren't even dogfooding their own format lol)