Address "implementation-defined" literal and type values

In [this thread](#911 (comment)) on #911, @macchiati and I discussed the handling of implementation-defined literal values and implementation-defined types.

This change splits the "MAY _accept_" for these two cases, permitting both and saving us having to say "... or an implementation-defined value..." in lots of places.

Author: aphillips

spec/registry.md

@@ -38,11 +38,23 @@ by any version of this specification
 for **standard** and **optional** functions.
 Such _options_ MUST use an implementation-specific _namespace_.
 
-Implementations MAY _accept_ additional _option_ values for _options_ defined here.
+Implementations MAY _accept_ additional literal _option_ values for _options_ defined here.
 However, such values might become defined with a different meaning in the future,
 including with a different, incompatible name
 or using an incompatible value space.
-Supporting implementation-specific _option_ values for **standard** or **optional** functions is NOT RECOMMENDED.
+Supporting implementation-specific literal _option_ values for **standard** or **optional** functions is NOT RECOMMENDED.
+
+Implementations MAY _accept_ implementation-defined types for _operands_ and _option_ values defined here.
+Such values can be useful to users in cases where local usage and support exists
+(including cases in which details vary from those defined by Unicode and CLDR).
+
+> For example, implementations are encouraged to _accept_ a native representation
+> for currency amounts as the _operand_ in the _function_ `:currency`.
+> Or a Java implementation might _accept_ a `java.time.chrono.Chronology` object
+> as a value for the date/time option `calendar`
+> or ICU4J's implementation might _accept_ a `com.ibm.icu.text.NumberingSystem` object
+> instead of using a [Unicode Numbering System Identifier](https://cldr-smoke.unicode.org/spec/main/ldml/tr35.html#UnicodeNumberSystemIdentifier)
+> for the option `numberingSystem` in _functions_ such as `:number` or `:integer`.
 
 Future versions of this specification MAY define additional _options_ and _option_ values,
 subject to the rules in the [Stability Policy](#stability-policy),