Code coverage not being meaningful because all instructions are always executed in order to make the crypto function constant-time is certainly a niche issue! It’s great to see such rigor going into Go.

Not assembly, but one of the side benefits of Go’s infamously verbose error handling is that code coverage generally tells you when you’ve never tested error cases. It gives a more fine-grained picture than languages using exception handling (unless you try/catch at a similarly fine-grained level).

Both branches are executed and the result merged, in single basic block fashion, which the code coverage tracker doesn't understand.

OK, sure. That could be fixed at the code coverage level - you're looking for something along the lines of store the select mask (as opposed to the bit branched on).

Could report it in similar fashion to the mcdc coverage, would look a bit like check each bit in the word is set or clear on some execution. Probably a reasonable extension to implement.