To get back to technical aspects, the sub-question of native code loading from JMODs/JARs has come up before. In 2018 I did some experiments with loading native code directly from memory (i.e. a JAR) on different operating systems, and wrote up the results here:
https://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-April/013762.html Linux had the best support, Windows was a runner up and macOS didn't support it at all - you'd have to just write it out to disk and reload. Dependencies between multiple native libraries was an open question. The JVM is flexible, and since 2018 Panama has done a lot of work to improve the internals of native code loading. It would be easy to make some prototypes of different approaches now. Jigsaw seems to be de-staffed so it's very much a case of "he who codes, wins" at this point - I don't think the Java architects are going to descend from a throne and issue a recommendation, given that the JDK and JavaFX already picked their own approach (SDKs with your approach 1). It may be worth taking a step back and asking to what extent is this need driven by inadequate build tools, vs a true lack in the Java platform itself. If Maven/Gradle worked better and the repository format more supportive of platform-specific modules, would these four different patterns matter at all? Put another way, what stops the JDK itself being hosted entirely on Maven Central? If those tools more fully embraced the jlink model then a lot of these questions and SPI-related busywork would go away.
