Thanks for starting this discussion back up!
I like this proposal. I believe the majority of desktop systems wouldn’t even need to define a stateVersion once all modules have been migrated.
So besides removing yet another footgun, for new users this would remove yet another piece of opaque magic, all without having to make any major changes to existing modules.
To keep context and threads linked, I suggested the non-version idea in this thread a little while ago.
This resulted, among other suggestions, in a proposal much like this one; it didn’t see much approval because this block of state versions for each module might grow rather big if it’s used by a lot of modules.
That said, in that thread we also concluded that a good number of uses of system.stateVersion are probably anti-patterns anyway; Most of the time it’s used to find “default” versions for software that cannot be upgraded with more than one increment at a time. Since then modules that do this have switched to the much more reasonable approach of making the now-ubiquitous package option mandatory.
So, to appease those fears, curb proliferation, and make future changes a bit less unachievable, could we add a step of defining specific use cases for which stateVersion is permissible, and perhaps even introduce review guidelines that’ll help enforce this?
Maybe we can also document what the stateVersion of each module is actually used for in its option?