It seems to me that PEP 517 is based on a model that frontends (and only frontends) call backends[1], and that’s the real issue here. Because that model doesn’t cater for the case of backends wrapping other backends[2].
What I’ve been doing is reading PEP 517 as talking about the responsibilities of callers and implementers rather than frontends and backends. Maybe that was never the intention, and there’s a way to read the PEP to understand the responsibilities of a caller that isn’t a frontend (such a caller might be a wrapper backend, or it might be something else like a utility library or an introspection tool) without concluding that the PEP says nothing about that case, but if so I’m missing it. If others can infer such an interpretation, I’d love to see a clarification to the PEP to help people like me understand better[3].
Note that I’m fine with the idea that callers might want to modify the metadata and see that reflected in the built wheel. That seems like a perfectly good use case that we’d simply not thought much about until now. But before we start insisting that existing backends change to support that, I’d like the standard to clarify that they are expected to do so, and to explain how an arbitrary caller should decide whether it’s a frontend (and so mustn’t change the metadata) or not (so it can).
To be clear, though, I’m not a backend developer, so I don’t have a stake in this. My only interest is to make sure our standards are precise enough for people to rely on them for interoperability.