In my experience the common source of darwin specific issues that linux contributors hit is package upgrades, not large stdenv changes. It’s more a “I managed to get my derivation working with this very gcc / glibc / linux specific patch. How do I make an equivalent very clang / libSystem / darwin specific patch?”.
Since linux stdenv and darwin stdenv are quite different, they use different libc, different c++ standard library, different c compiler, it’s not as common for changes to one to affect the other, and the people making changes to one of the two are usually knowledgeable enough about the platform specific issues to fix them up. They might not be knowledgeable enough about package specific issues that happen due to large changes, which can result in the issues raised in Nixpkgs's current development workflow is not sustainable, but that’s a different matter.
If the upstream doesn’t support darwin, there’s no expectation that the package in nixpkgs support darwin. And upstream darwin support also uses clang and libSystem just like we do. So generally the issues are due to the nixpkgs specific patching required. If the patches are in the part of the code that is in common between linux and darwin upstream, then the same patch will likely work for both. If the patches are in the part of the code that is specific to one of the two platforms upstream, like specific configure flags / compiler flags, then they will have to be platform specific.
Here’s an example where a linux specific fix needs a darwin equivalent: https://sourcegraph.com/github.com/NixOS/nixpkgs@fff82404c8f28eb52be539aecab51fa4767d79f0/-/blob/pkgs/development/compilers/sagittarius-scheme/default.nix?L13-15.
Maybe a linux contributor updating a package will figure out how to use LD_LIBRARY_PATH in the build to make it work, but they might know about the darwin equivalent, DYLD_FALLBACK_LIBRARY_PATH.
Here’s an example where similar, non-system specific patches have to be applied to multiple system specific files in the upstream: https://sourcegraph.com/github.com/NixOS/nixpkgs@42b5817e6b94974614cc9d0f803c14551274d6c5/-/blob/pkgs/tools/networking/tuntox/default.nix?L46%3A1-57%3A1.
There’s also different dependency closures across the two systems: maybe the linux build requires openssl but the darwin build uses apple_sdk.frameworks.Security, or the linux build uses qt but the darwin build uses apple_sdk.frameworks.AppKit. Usually the more upstream supports macOS natively, the bigger the divergence.
Any time a linux contributors hits anything like this, they don’t have the system available to develop these darwin specific changes, no matter how small or simple they might be, and even if they wanted to have one, it would require buying specialised hardware. macOS virtualisation is only supported on macOS hosts, and I’m not sure how feasible it is to run a non-macOS darwin system. Even if they have a good idea of what the change required is based on other packages or comments by reviewers, it might take multiple rounds of waiting for ofborg to build the derivation to confirm the correct syntax / specifics, and the queues and build performance might not be good.
I said earlier that in my experience ofborg performance for darwin is not too different from linux, but at the same time I have systems for both darwin and linux development, so I don’t have to wait on ofborg for either. Someone who only had a darwin system would hit the same issues and frustrations as someone only having a linux system, but at least virtualising linux is easy enough and well supported in most cases.