I think this should be SHOULD.

I know we're discussing the ICU4X objection. The common use case for this option is is basically "I18N demos", which I write a lot of 😉:

The default date format in locale: {$locale :x:localeGetDisplayName} is {$now :date u:locale=$locale}

There are cases in which users wish to tailor the locale, for example using the -u extension for options but do not wish to transmit the "decorated" locale everywhere. Some of these items are option values on built-in functions, but overriding (for example) the digit shaping in the locale works for functions that have no such options.

A fairly common case is wanting to override the locale to be und/Locale.ROOT or some POSIX variant to get a locale-neutral representation.

Encouraging implementations to provide this feature with the stronger normative SHOULD does not mean that implementations that cannot support it are "bad".

I don't think i18n demos is a use case that we ought to support if/as it adds complexity to an implementation.

If the numbering system is desirable to fix for a single function in a single message, wouldn't it also be desirable to fix for all messages, and therefore be encoded in the locale that's used to format the message or messages?

For ensuring that something is formatted in a locale-neutral representation, wouldn't a programmer want to submit that to the message formatter in a pre-formatted form, to guarantee that localization will not affect it at all?

Consider a case like:

The message shouted: {$text :transform type=uppercase u:locale=$textLocale} <- what if the string is Turkish?

There are other cases. I think that on-going discussion suggests moving u:locale to draft and that we rebuild a design document rather than including it in 47 as stable.

Thank you very much for illuminating a use case; this is more than I've seen before.

However, I'm not convinced this rises to the level of a SHOULD.

Here's my litmus test: if you are in a situation where you are able to choose your MF implementation, then your use case is a MAY. If you are in a situation where your environment chooses your MF implementation for you, then your use case is a SHOULD.

Given that Addison is writing his own strings for his own personal use, I think this lands in the MAY category.

Given that Addison is writing his own strings for his own personal use, I think this lands in the MAY category.

I don't understand this statement? Every MF2 user is "writing their own strings for their own personal use"? Do you mean "you're writing your own function :transform"?

Most users will be in situations in which their MF2 implementation is the one in their platform or in a library such as ICU. Their goal and task is to write messages, not to cherry-pick different choices.

I don't think we have time this morning to make u:locale satisfy everyone and I think we should employ our WG process--which requires a design doc. We have ample time in v48 to do this correctly and zero time to get it right just now. Hence, I propose moving u:locale to DRAFT.

I don't think we can or should make any u: option MUST in this release, but really everyone should implement this feature. Otherwise string metadata about direction has nowhere to go. For those playing at home, my UTW presentation explains why.