First of all: MKPs with old versioning should still work (and compare “older” to valid semver versions). If that is not the case please send us feedback via the beta channels!
As for when you edit an MKP (== create a new version of it):
Sorry, maybe I was a bit unclear. We’re enforcing the format of a semantic version number, but not the semantics of it.
The semantics clearly describe which part of a version number must be incremented depending on how the software package changes and vice versa. That is a very powerful tool in software development, but it requires a lot of discipline and might be overkill for regular MKP maintenence. We cannot (and don’t need to) enforce that.
But since you can now have more than one version of a package in your site, we need a reliable, transparent and predictable way to order the packages, so we had to introduce some sort of standard. Using the format of a semantic version number allows sorting, and there’s no reason not to go with the industry standard.
Now, a wild guess: You want to include the date, rather than <major>.<minor>.<patch> version. That is not the intended semantics, but you can do that anyway. Just make sure it fits the format, for instance 2023.04.04-v.0.9 should be ok. Note that 2023.05.05-v.0.1 will be considered newer then.
The “semver” way would be to use the build information field, I guess: 0.9.0+2023.04.04, but that is entirely up to you.