So this is a bit of a trade-off. Apparently dak actually now permits different overrides for different architectures. There are some corner cases where this is useful, generally around priorities: for example, hfsutils should strictly be Priority: standard on powerpc, where HFS filesystems are common, but Priority: extra on other architectures. We have a consistency-check script that's been warning about that particular inconsistency and a couple of other similar ones for some years now ...
That said, I don't think this should influence the design of NEW queue handling, because there are a handful of cases like this in the whole archive and they rarely change. I think my recommendation would be, if it's possible, to assume that the same overrides should be applied across all architectures when they're going through the NEW queue, but to permit single architectures to be overridden later using change-override.py. If that is impossible, then it wouldn't be the end of the world to just assume that overrides will always be the same on all architectures.
That said, NEW queue handling is much less of an issue nowadays in practice; the bulk of it is scripted.
So this is a bit of a trade-off. Apparently dak actually now permits different overrides for different architectures. There are some corner cases where this is useful, generally around priorities: for example, hfsutils should strictly be Priority: standard on powerpc, where HFS filesystems are common, but Priority: extra on other architectures. We have a consistency-check script that's been warning about that particular inconsistency and a couple of other similar ones for some years now ...
That said, I don't think this should influence the design of NEW queue handling, because there are a handful of cases like this in the whole archive and they rarely change. I think my recommendation would be, if it's possible, to assume that the same overrides should be applied across all architectures when they're going through the NEW queue, but to permit single architectures to be overridden later using change-override.py. If that is impossible, then it wouldn't be the end of the world to just assume that overrides will always be the same on all architectures.
That said, NEW queue handling is much less of an issue nowadays in practice; the bulk of it is scripted.