Libgdx 1.12.0 LWJGL3 Migration: Dual‑Backend Support for Desktop Targets?

Goal

Upgrade a legacy Libgdx 1.11.x project to 1.12.0 while retaining the ability to run on the old LWJGL2 backend for legacy desktop users and the new LWJGL3 backend for modern builds.

Constraints

• Gradle 7+ is required; the libgdx plugin now exposes a lwjgl3Natives configuration and platform‑specific classifiers (natives‑windows, natives‑linux, natives‑macos).
• LWJGL3 replaces GLFW, OpenAL, and STB; its native jars are not compatible with LWJGL2 binaries.
• The gdx-backend-lwjgl3 artifact cannot coexist with gdx-backend-lwjgl in the same Gradle source set due to overlapping package names and classpath conflicts.
• Third‑party extensions (Box2D, FreeType) must be aligned to the same LWJGL version; mismatched extensions cause runtime UnsatisfiedLinkError.

Unresolved Decision

Is there a supported configuration or plugin that allows a single project to compile and run both LWJGL2 and LWJGL3 desktop backends, selecting the appropriate native libraries at runtime without manual reconfiguration?

Specific Questions

• Can a Gradle multi‑module layout or a custom source set provide isolated classpaths for LWJGL2 and LWJGL3 while sharing shared Libgdx core code?
• Does Libgdx offer a runtime flag or wrapper to switch between LwjglApplicationConfiguration and Lwjgl3ApplicationConfiguration within the same binary?
• What are the recommended practices for managing native dependencies (GLFW, OpenAL, STB) when supporting both backends simultaneously?