Building 1.74.0 natively on NetBSD/powerpc results in "pattern `Some(_)` not covered" error message

While trying to build 1.74.0 natively on NetBSD/powerpc 10.0_BETA, I appear to be unable to cross this problem by myself. It doesn't look like the armv7 or aarch64 NetBSD targets are similarly affected, so this is probably more a powerpc issue than a NetBSD issue.

     Running `/usr/pkgsrc/wip/rust174/work/rust-bootstrap/bin/rustc --crate-name build_script_main --edition=2018 /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/typenum-1.15.0/build/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C metadata=ef76ccfc9e00eb4a -C extra-filename=-ef76ccfc9e00eb4a --out-dir /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/build/typenum-ef76ccfc9e00eb4a -L dependency=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/deps --cap-lints allow -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings`
error[E0004]: non-exhaustive patterns: `Some(_)` not covered
   --> /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/version_check/src/lib.rs:290:11
    |
290 |     match is_feature_flaggable() {
    |           ^^^^^^^^^^^^^^^^^^^^^^ pattern `Some(_)` not covered
    |
note: `Option<bool>` defined here
   --> /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/library/core/src/option.rs:571:5
    |
563 | pub enum Option<T> {
    | ------------------
...
571 |     Some(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     ^^^^ not covered
    = note: the matched value is of type `Option<bool>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
293 ~         None => return None,
294 ~         Some(_) => todo!(),
    |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `version_check` (lib) due to previous error

Once again I solicit assistance about how to cross this hurdle.
And ... why does this happen just for this target?
At least this hurdle appears to be consistent / reproducible...

Start at vendor/version_check/src/lib.rs:290, where the NetBSD/powerpc build reports the non-exhaustive match, and reproduce the native Rust 1.74.0 build shown in the issue. Compare the behavior with the armv7 and aarch64 NetBSD targets to identify the target-specific cause. Done means the native NetBSD/powerpc build completes without this error and the cause is explained.