The publisher could do this yes, but the end result to yourself in my opinion wouldn’t be much different. When you use build-snaps, the content is put directly into your snap, it’s not a content snap where that content can update separately when a separate snap updates. Whether you use the snap or the apt package, you’re still responsible for rebuilding the snap from time to time, so the end result doesn’t change much (apart from it runs). I’m also unsure, but would have no reason to believe e.g Dotnet 8 as a snap would have more than 3 years security support even as an LTS, but both 7 and 8 would have 10 years as a stage package, apt is explicitly covered by general Ubuntu security policies but I’ve no idea about the Snap, you’d have to ask the publisher.
Did Snapcraft in the CI not do similar? There should be a library linter that is run, and while it won’t find everything, it’s not magic hardcoding. I’d have thought there’d be a warning in the build saying that “libraries were expected but not found” (paraphrased). It won’t outright stop the build because it’s not always a deal breaker but you could adjust your CI process into highlighting if this errors.
I think unfortunately adding special cases to detect errors would probably not go down too well because the incompatibility matrix is effectively infinite (you’re basically saying A is only ever compatible with B). Any single snap can be viable as a build-snap so there’d be tennes of thousands of combinations to test, alternatively you leave it to “common” snaps and inevitably end up missing something. Some stage-snaps might not have compiled code and might even run everywhere (e.g a trivial Python script).
IMO, if you were to treat this as a feature request rather than a bug, you’d need to contact the dotnet packagers, which brings another problem:
dotnet-sdk is possibly becoming dotnet (SDK and Runtime bundled!)
Your request around aligning tracks to cores makes perfect sense, so ultimately it’d come down to whether it justifies the effort on their end. The post says it’ll be owned by the Canonical Foundations Team but doesn’t yet provide a way to contact them (because until now I believe it’s been owned by Microsoft directly).
If you believe snapd could do it better, then that’s an easier place for a bug report, snapd in Launchpad
But ultimately I believe the technically correct and easiest answer for everyone involved is to prefer the Apt package via stage-package, you can see that’s exactly how I’ve been doing it in e.g Pinta since Canonical officially published C# packages!
Before that I was still doing it via Microsoft repositories directly because the dotnet-sdk snap otherwise cause me similar problems it’s causing you here.
I believe you could potentially add the revision ID to stage-snaps to get the exact same reproducible version everytime, but you’d be getting no security or bug fixes too and the pain is you’d need to know the revisions in advance.
IMO, using Apt for C# in snaps like this isn’t a workaround, it’s objectively the best solution in this context and I’ve been sat happily doing that 2-3 years on the official dotnet apt packages already.
The net snap is IMO quite clearly intended for developers/users of NET in traditional environments, not in snaps themselves.