stdenv/generic/check.meta consists of several kinds of "refusing to evaluate" checks, messages, and remediation mechanisms, ranging from unsupported or unfree packages to broken or maintainer-less packages. However, no consistent way exists to determine whether a package has been meta-rejected (not even builtins.tryEval).

In addition, we have a user-defined rejection meta.broken, but it doesn't allow developers to specify the reason for the breakage/constraint, potentially leading to the hacky disabled pattern implemented with lib.extendDerivation being adopted by language-specific build helpers such as buildPythonPackage. lib.extendDerivation is low-level and is known to break the functionality of existing overriders of a package, including overrideAttrs, making it hard to get rid of custom overriders (such as overridePythonAttrs) and their maintenance overhead.

The following enhancement would help solve the issues:

• A unified way to determine whether and how a package is meta-rejected.
• An interface to show custom reasons for meta-rejection.
• Reasonable overriding capability of the meta-rejection switches.

(I tried to write a Nix RFC for this but was not competent enough to tackle such infrastructural design.)