This will respect doCheck = false; overrides

Doesn't it already?

nix-repl> hello.doCheck                                      
true

nix-repl> (hello.overrideAttrs { doCheck = true; }).doCheck
true

nix-repl> (hello.overrideAttrs { doCheck = false; }).doCheck
false

nix-repl> hello                                    
«derivation /nix/store/nvl9ic0pj1fpyln3zaqrf4cclbqdfn1j-hello-2.12.1.drv»

nix-repl> hello.overrideAttrs { doCheck = true; }            
«derivation /nix/store/nvl9ic0pj1fpyln3zaqrf4cclbqdfn1j-hello-2.12.1.drv»

nix-repl> hello.overrideAttrs { doCheck = false; }
«derivation /nix/store/6n4az7cnydvgj1ixk4bmg50vx7nih3xm-hello-2.12.1.drv»

Fwiw, it wouldn't work with cleanAttrs when going through finalPackage.
Also theoretically you could "fake it" with passthru then.

Consider:

On master, without finalPackage:

nix-repl> libspatialindex.cmakeFlags                                 
[ "-DSIDX_BUILD_TESTS=ON" ]

nix-repl> pkgsCross.aarch64-multiplatform.libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=ON" "-DCMAKE_SYSTEM_NAME=Linux" "-DCMAKE_SYSTEM_PROCESSOR=aarch64" "-DCMAKE_HOST_SYSTEM_NAME=Linux" "-DCMAKE_HOST_SYSTEM_PROCESSOR=x86_64" ]

with this PR:

nix-repl> libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=ON" ]

nix-repl> pkgsCross.aarch64-multiplatform.libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=OFF" "-DCMAKE_SYSTEM_NAME=Linux" "-DCMAKE_SYSTEM_PROCESSOR=aarch64" "-DCMAKE_HOST_SYSTEM_NAME=Linux" "-DCMAKE_HOST_SYSTEM_PROCESSOR=x86_64" ]

Right, I forgot that mkDerivation applies some logic between doCheck coming in and doCheck going out.
Makes sense. It's unfortunate that we don't have a more direct way to access that outgoing doCheck, but I don't see a good enough alternative that doesn't massively rewrite make-derivation.nix, other than yours!

Either the cross logic needs to take place during the finalAttrs fixed-point, or we do this everywhere.

It would be a bad idea to set this by default in mkDerivation, would it?

doCheck is by default false as i understand.

fix the underlying issue?

A redesign of mkDerivation, under a new name. This is a hard problem because of the requirements

• stay as close as possible to the mkDerivation
• share as much implementation as possible with mkDerivation. A piece of the puzzle is to expose the currently (badly) encapsulated logic by refactoring mkDerivation into
  • a simple transformation of attributes (mkDerivation arguments to derivation arguments)
  • a mkDerivationOverridable that deals with adding the (legacy?) overrideAttrs and wrapping the outputs to resemble the expected package
  • a short and sweet mkDerivation that pulls it all together
• try to be future proof with RFC 92, and multi-derivation packages, both of which change the concept of a package attrset to be properly distinct from the derivations that build it
• not use the module system because the Nixpkgs graph is big enough that we care about performance penalties, even if they're only constant-factor
• incorporate module system ideas without the feature creep of wanting to do all the things we know we could do because of the module system
  • must have: a hierarchy of approximately two levels, corresponding to the attribute sets that exist at each "stage" of package construction. As an example, see e.g. __cleanAttrs: Clean packages that don't expose all internals #217243 (comment)

Note to self: put these two comments under a new issue to further discuss such a design, because this is starting to go off-topic, especially possible responses, and ping the Nixpkgs architecture team.

We could maybe lift most cross logic out of stdenv.mkDerivation and rather compose it in using overrideAttrs.
EDIT: i re-read your second point, which basically states this

But onto something more immediately actionable: are we good to merge this?

Yes, thank you for reminding me. Architecture improvements (like I suggested) should follow from things we find problematic in the code, not the opposite where we wait for beautiful elegant whatever before we solve our actual problems.