I'm not sure if this would be helpful here. These numbers correspond to the possible choices in the SSE implementation, which processes 16 bytes per vector (thus 16 possibly misalignments) and 32 bytes per iteration (thus 64 bytes total length to complete the main loop at least once). If I change the code such that these values change, I plan to bump the unit test to cover the extended range.

The same applies to the other cases and in fact pretty much all the string unit tests I have written so far. I can add some arbitrary symbolic names for these numbers, but I don't see how that improves things, it just adds more clutter. If you insist, I can try and do some systematic refactoring to add symbolic constants at a later point, but it makes the unit tests less useful as a development tool for me, as it becomes harder to modify the numbers when the code changes.

My main priority is to get the fix for 293915 in right now.

nit: I would specify alignas(16) for better repeatability. I'm not 100% convinced it won't fail on i = 4 for one version of the compiler, but 8 for another, if the stack layout is changed

Indeed, but it'll cycle through all alignments anyway and the specific iteration it fails on doesn't really matter.

The choice is arbitrary. X is the character we are looking for, - is some other character. They were chosen to be easy to distinguish visually when inspecting a test suite failure in the debugger. Unit test values goes through all possible characters to try to catch arithmetic errors in the scalar kernel (cf. 3d8ef25).