Two use cases I can remember where this would be useful:
I have a runtime typechecking module, and I want to support adding custom types. I can either add them into the module or have a different module and have the typechecker require that module. There is a third option, externally modifying the typechecker module, but this will lead to race conditions because I don’t want to add the complexity of priority loading in my framework.
I have a player data saver and replicator, the core logic is the same no matter how the data is organized, but I need a separate module to define what the data looks like and how it should be (de)serialized. (Here I’ve skipped repeating options 1 & 3 and just assumed 2).
Both of these modules ought to be generic to my framework, and I want to use packages with these generic parts of my framework. I think option 2 is the best (creating config modules), so the question is where should these config modules go? The most natural answer to me seems to be as a child of the generic modules. But the generic module is inside a package and the config modules are specific to each game! This is why I want a package blacklist
A feature of the Unity game engine is something called Prefabs which are very similar to Packages in Roblox. A key difference is that you can publish your game with unpublished changes to prefabs. Also, if the root prefab is modified the change will apply to all copies of that prefab including ones with pending changes.
If this were in Roblox what it would mean is if say you have a package that is nothing but a module script with some attributes attached and then put a config module as a child. Then, in another instance of the package change the code in the module and then publish it. your copy of the package with the config as a child would still update but just leave the child untouched.
This would also mean you could modify the attached attributes and then the package will update and the code of the module will be replaced but the changed attributes will not.
Unity also keeps track of which properties (and if this were in Roblox then also attributes) have been changes and which ones are still set to the default.
What this would mean for Roblox is that if you were to change a property or attribute of the root package then the instance of the package will check if that property is not its default on that instance. If it is not default, then it will leave it that way. If the instance of the package still has that property or attribute set to the package’s default then it will update to the new default. Properties would also be able to be reset to the package’s default by right clicking them and either clicking “apply” to publish that specific property’s value as the new default, or clicking “Reset to default” to reset that property or attribute to its default value.
Such a system would be amazing to have in Roblox.
Let me know if this makes any sense.