This has to be undone as it doesn't play nicely with any of the versioning tools (command line, maven, IDE, dependabot, rennovate, etc) or CVE tooling.

Please provide a concrete example of a problem.

Each of those tools works with the /jetty-ee#/ tree in isolation (as we don't want changes in /jetty-ee9/ to impact /jetty-ee10/ for example).

Changes in jetty-ee9 are still absolutely isolated and have no impact on any other module. Nothing about this change impacts in any way the build relationship between any existing modules.

Putting these properties in the top level pom hides them from all of those tools, and those versions cannot be updated in isolation from each other.

Please provide a concrete example, and an explanation of why these tools cannot be reconfigured to refer to the top level pom properties instead.

Also, In the future, if we go with git submodules, this change cannot exist.

Not an argument for the present. Moreover, all the jetty-eeX modules already depend on properties that are declared in the top level pom, so if we do go to git submodules in the future we would have to face this problem anyway.

This also prevents merging of jetty-12.0.x versions in a reliable way.

Merging from jetty-12.0.x is already problematic, so I don't think this is a showstopper.

I'm willing to look at other solutions, but the solution is not to duplicate dependency version information.