Add design doc for error handling

exploration/error-handling.md

@@ -45,6 +45,18 @@ because returning more than 1 error would require heap allocation.
 they found over the 25 years of maintaining the library that there was more cost than benefit in additionally providing error information with a default best effort return value compared to just returning the default best effort value.
 The additional constraint in ICU4C's C++ style to return an error code rather than throwing errors using the STL further complicates the usefulness and likelihood to be used correctly by developers, especially during nested calls.
 
+> [!NOTE]
+> The wording in this document uses the word "signal" in regards to providing
+> information about an error rather than "return" or "emit" when referring to
+> a requirement that an implementation must at least indicate that an error has
+> occurred.
+> The word "signal" better accomodates more alternatives in the solution space
+> like those that only choose to indicate that an error occurred,
+> while still including those that additionally prefer to return the error
+> itself as an error object.
+> (By contrast, "return an error" implies that an error object will be thrown or
+> returned, and "emit an error" is ambiguous as to what is or isn't performed.)
+
 ## Proposed Design
 
 The following spec text is proposed:
@@ -87,6 +99,26 @@ For example, in ICU,
 [the suggested practice](https://docs.google.com/document/d/11yJUWedBIpmq-YNSqqDfgUxcREmlvV0NskYganXkQHA/edit#bookmark=id.lx4ls9eelh99)
 is to avoid additionally returning optional error codes when providing best-effort formatted results.
 
+### Require a best-effort message value and signaling of an error
+
+> In all cases, when encountering an error,
+> a message formatter MUST be able to signal an error or errors.
+> It MUST also provide the appropriate fallback representation of the _message_ defined
+> in this specification.
+
+This alternative maintains that an implementation must both return a best-effort message
+and must signal that an error has occurred.
+Compared to the current text,
+this alternative slightly loosens the constraint of 
+returning an error into only needing to signal an error.
+
+Similar to the current spec text,
+this alternative requires implementations to provide useful information:
+both a signal that an error occurred and a best effort message.
+A downside to this alternative is that these requirements together assume that
+all implementations will want to pay the cost of constructing a representative mesage
+after the occurrence of an error.
+
 ### Allow implementations to determine all details
 
 > When encountering an error during formatting,