I was reading through the form-extension path and noticed Form.process calls itself with the first two arguments in a different order to the method's own signature and to the other two call sites, which is what put me onto this.

1. Form.process recurses into the inherited form at Form.java:224 as parent.process(constants, globalConstants, forms), so the global map and the form-set map are swapped relative to the declared process(globalConstants, constants, forms).
2. Field.process applies the form-set constants first and the global constants second, so for a shared constant name the form-set value is meant to win; because of the swap a parent form reached through extends resolves that constant to the global value instead, the opposite precedence to a non-extended form and to the correct calls at Form.java:240 and FormSet.java:312.
3. Restored the declared argument order on the recursive call, and added a regression test in ExtensionTest that extends a base form sharing a constant name with a global one and asserts the form-set value wins; it fails before this change (expected: <formset> but was: <global>) and passes after.

Left unfixed, any form that uses extends together with a form-set constant overriding a like-named global constant silently picks up the wrong value, and which value wins also depends on the form iteration order, so it is not deterministic across runs.

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.