This is doing two very different things and I think they should be separated:

1. Extracting the int64 complexity. Should be fine but should be done in isolation.
2. (Ab)using stl-internal-check to activate fallback coverage. I really, really don't like this. This means that we're testing something wildly different than what we're shipping. In general, product code shouldn't behave differently for stl-internal-checks; we've made a highly limited number of exceptions for this (e.g. disabling access control to allow tests to mess with invariants) but this is going too far in my opinion.

I am confused as to what this fallback coverage actually is (I am a little more familiar with ARM64EC these days but my understanding is still fragile). Can you explain in simpler terms what this is trying to do, and why we have to exercise modes that aren't usually enabled for users? I could potentially be open to adding an off-by-default mode that the tests could optionally activate (in addition to testing vanilla modes) but I want to understand why.

• Extracting the int64 complexity. Should be fine but should be done in isolation.

Then it should go first. Exercising the fallback without extracting int64 complexity becomes way too complicated.

Can you explain in simpler terms what this is trying to do, and why we have to exercise modes that aren't usually enabled for users? I could potentially be open to adding an off-by-default mode that the tests could optionally activate (in addition to testing vanilla modes) but I want to understand why.

Here you are mentioning #5998 (comment):

I think the ARM64EC vector_algorithms.cpp is used when x64 user .obj files are linked into an ARM64EC binary. That's why the ARM64EC surface must always match the x64 surface.

I'm confident that if this explanation is correct, then used in it means called. Since there's a scenario where they area called exists, we need some coverage to avoid #5993 regression.

Additionally, this will help catching complete omission of such callbacks in newly vectorized function without having to check exports.

This means that we're testing something wildly different than what we're shipping.

I understand this disadvantage. But I think the need for coverage of these outweighs the disadvantage.

Ok, let's do the int64 separation first, then we can think about exercising the ARM64EC scenario.

Closing, will open the int64 PR instead