cpp module is broken on macOS if architectures is not being multiplexed / declaration order issue?

Building the auxiliaryInputsFromDependencies autotest on macOS with the 'none' profile fails:

ERROR: /Users/jakepetroules/Builds/build-qbs/darwin/tests/auto/blackbox/testWorkDir/aux-inputs-from-deps/aux-inputs-from-deps.qbs:13:5 Error while handling product 'p':/Users/jakepetroules/Builds/build-qbs/darwin/share/qbs/modules/cpp/GenericGCC.qbs:264 The following properties are not set. Set them in your profile or product:cpp.architecture: you might want to re-run 'qbs-setup-toolchains'The following properties have invalid values:cpp.architecture: 'undefined' differs from the architecture produced by this compiler (x86_64)

If "architectures" is added to multiplexByQbsProperties in the "p" product, the resulting build continues along just fine, or if the "app" product is removed, the build continues along just fine (even though the affected product is "p").

In any case the GccProbe runs just fine, it just seems that the qbs.architecture binding in GenericGCC doesn't take effect in the failure case.

The java and javaDependencyTracking tests and numerous other blackbox tests all exhibit the same issue. It's been obscured from our view in the past because the CI runs all tests with a Qt-based profile, so qbs.architecture is always set. The issue cannot be reproduced on Linux.

It was hard to pinpoint exactly what's going wrong here, but I was able to create a minimum reproducible test case. It actually appears that this issue is triggered by the mere declaration order of product items in a project. Consider the following project builds fine:

// OK
import qbs
Project {
    Product { name: "a"; Export { Depends { name: "cpp" } } }
    Product { name: "b"; Depends { name: "a" } }
    Product { name: "c"; multiplexByQbsProperties: ["architectures"]; Depends { name: "cpp" } }
}

but this one exhibits the failure (b and c are simply declared in the opposite order):

// NOK
import qbs
Project {
    Product { name: "a"; Export { Depends { name: "cpp" } } }
    Product { name: "c"; multiplexByQbsProperties: ["architectures"]; Depends { name: "cpp" } }
    Product { name: "b"; Depends { name: "a" } }
}

Multiplexing somehow seems to be involved, since "c" with a CppApplication template also exhibits the issue and multiplexByQbsProperties containing architecture is otherwise the only credible difference between macOS and Linux. The oddest bit is that a failure in b is introduced by the mere presence of c in the project even though it is otherwise totally independent.