Description
The current spec (spec/errors.md) says:
In all cases, when encountering a runtime error,
a message formatter MUST provide some representation of the message.
An informative error or errors MUST also be separately provided.
These are two MUST, with an "and"
This goes against the way many programming languages and frameworks handle errors.
For example ICU4J either returns a fallback string, or throws.
Rust returns a Result, with Err or Ok fields.
But it is an either / or, can't set both.
Similar for JavaScript, and in general many programming languages and frameworks.
Many platforms have mechanisms that load a string from resources and format with parameters, in one step.
With the API designed many-many years ago, and can't be changed.
For ICU Tim filed https://unicode-org.atlassian.net/browse/ICU-22762
But I think that the ICU answer to that issue is not relevant to this.
TLDR:
This is a standard that applies to all programming languages and frameworks out there, now and in the future.
It is not its job to force an implementation to do error handing against its native style.
We can recommend, and an implementation might choose to come up with a mechanism, which might or might not be the one described above. For example might provide format and formatStrict methods, which are also against the current spec.