My organization is testing a bespoke JDK distribution that includes `libgraal` and GraalJS, which require experimental launch flags to enable. To make this easy for customers to pick up, we have overridden the defaults to set `+UnlockExperimentalVMOptions`, `+EnableJVMCI`, and `+UseJVMCINativeLibrary`. The JDK then "just works" for them by swapping in the custom JDK, without any changes to the code launching their system. On the whole, this is working great.

However, this configuration breaks several jtreg test cases that make assumptions about the default options. It seems reasonable that these assumptions be declared in `@require`, but not all of the right properties are avaliable.

In the draft PR https://github.com/openjdk/jdk/pull/21233 I add a jtreg `@require` property to surface the value of `UnlockExperimentalVMOptions` and update two tests that assume the flag is false. This makes these tests resilient to changes to the default state of that flag. (I have one or two similar changes in the works for assumptions about the other flags.)

Before taking that PR out of draft, its worth ensuring alignment on the overall approach. My perspective is that centrally encoding such assumptions into the tests is more robust than maintaining problem lists within each distro that diverges from the defaults.