For this PR, I am certain that we should always report system: even for a bytecode-only build, because that's related to how the C compiler is called, and so forth.

The argument is less clear for arch: and model: but I would put it that it is surprising to be able to see the difference between ocamlc -config where configure had --enable-native-compiler and ocamlc -config on the same system where configure had --disable-native-compiler.

I'll let @dra27 and @Octachron decide whether to cherry-pick to 4.12.

Thanks, @xavierleroy! It receives occasional use by me (which is how I discovered it) since I think we still don't have a way to tell ocamltest to do the old BYTECODE_ONLY=true in the testsuite, so I end up using this out of laziness.

Just for the proverbial record, we do ship a +bytecode-only switch to opam, and apparently it's used enough that a bug in the 4.12 experiment with having new package options was noticed (and fixed).

Entirely up to @Octachron where 4.12 is concerned.

A configuration fix seems fine for 4.12 .

If this is cherry-picked to 4.12, #10074 must be cherry-picked also.

The argument is less clear for arch: and model: but I would put it that it is surprising to be able to see the difference between ocamlc -config where configure had --enable-native-compiler and ocamlc -config on the same system where configure had --disable-native-compiler.

On second though, the "surprising" behavior was the correct one, given that arch = "none" was the traditional way to test whether ocamlopt is supported or not, see ocaml/opam-repository#22689 .

Just for the proverbial record, though, the test has never been a (portably) reliable test for ocamlopt: the Windows config/Makefile.* used to set all three regardless:

Actually, that argument is a bit specious for those manual Makefiles (if one were building a bytecode-only Windows compiler, one should have changed ARCH to none, of course). What isn't (and is more relevant now) is that num only selects the optimised versions of its C implementations (which are still used in the bytecode stubs) if ARCH is set. As things stand, we get num breaking noisily on the bytecode-only arches in 5.0, where for at least ppc64 (and i386/arm32 FWIW) they would otherwise have silently switched to the generic implementations 🤷