You've gotten really good at talking matter-of-fact about things you aren't trustworthy authority on. How many codebases have you interacted with or have watched start from alpha to completion that totally couldn't implement mod support because it's "Too expensive"? Do you honestly believe one has to literally reinvent the wheel in order to add mod support?
you don't have to have a masters in computer science to know that if you derive 200 classes from one deprecated interface, you'll have to go back and change all of those 200 classes if you use a new interface. mod support is incredibly hard to achieve later on in development. it's not as easy as just go back and change a few lines of code so that they're public, you have to go in and add callbacks and hooks so that other assemblies can supply their own logic. it's a scale problem, and as the project grows the problem becomes bigger and bigger. i'd haul out my second edition of code complete from the closet and copy and paste the entire chapter on development costs and how scaling and scope influences it but i dont think you deserve it
Sure it's not loving easy to add modding support once the official release builds are pushed out, but considering this is basically their passion project, they have no deadlines and this is the only thing all of the developers are working on, if they waited until the last moment to start developing mod support it probably wouldn't take that long to implement. You're doing a lot of ass-pulls about a codebase you haven't done any research on and you're saying matter-of-fact statements about design philosophy you don't have any legitimate experience with. But sure, go on and keep writing paragraph upon paragraph about it like it means anything to anyone, and keep pretending you give a stuff, it's only your time that you are wasting.
i dont know why you keep mentioning codebase like cpp has some special god-tier tool that allows you to inject mod support into any system on your solution. its not even some super enigmatic field of design, it's just common sense. you build the foundation before you build a house, because you can't just lift up the house and change the foundation in post.
it took 8 years since it's launch for minecraft to get mod compatibility. Once the 1.6.X updates rolled out around, how item and block IDs were referenced and used were directly restructured so more items and blocks, and items with changing properties were easier to add, for both future updates and mod content, which by that point about four years after the game's release, already had a whole host of mod content. The first widely used third-party API, Bukkit, was released only about one and a half years after the game's first few public builds. The game never really got it's official modding API release because from what it sounded like, third party content was already filling that role sufficiently.
Bukkit isn't that good. it only solves the superficial mod conflicts when two mods reference the same class, but from there not much can be done. because callbacks dont exist in the vanilla minecraft code, two mods cannot hook into the same methods unless they're entirely additive mods (add outside content). if you wanted to make a mod that dropped two dirt items instead of one when you break a dirt block, you had to recreate the entire dirt class from scratch and use that instead of vanilla dirt.
If minecraft had actual mod support, they'd have callback interfaces that any class can publicly add their own logic on to so all mods can supply their own logic to default methods without fear of conflicting. this is something that bukkit can't really do because it requires rewriting a lot of classes from scratch. even making some kind of IModdable interface is hard because you need to expand that into IModdableBlock and then IModdableMob and then each subcategory for special methods each uses. I'm sure blocks all share their own constructor and destructor and that's a great place to add callbacks but many of the other blocks have their own logic, like doors and switches with states, or ice and mud that slow you down.
Historically, mod content for unreal games required you to work with a modified unreal engine studio tailor-made to mod the game. I have no loving clue what you mean by the native blueprint and package systems aren't an actual modding system, this sounds like someone talking out of their ass would say. Arguing semantics is handicapped, but anything with modified files or user-generated content is a mod, anything that facilitates modification or creation of third party content is a "Modding system."
not only is the sdk that would come custom made for brickadia like 50 gb, but the developers still have to add their own package management in order to prevent people from just making whole builds and redistributing them as the mod itself (see: vanilla blockland). and even then its all pretty damn limited, we'd be forced to use blueprints, which suck.
i know you like to look at mod support as this hollow definition of changing a video game, but there's definitely levels to it. blockland has really good mod support because not only can you add new content to the game, you can change content that already exists. i don't know the landscape of blueprints but i'm guessing its entirely additive and you can't actually change baked content in the game. things like ammo systems on an additive mod support system are basically impossible because you wouldn't have access to firing methods of other classes.