Stanisław Małolepszy

@aphillips: > However, I think it's too specific. This would require implementations to write their internals in specific ways (and we'd have to create tests to prove that the implementation...

While I'm not opposed to this change, I'd like to note potential reasons to prefer arrays over maps: * With maps for options, the serialization of a message becomes unstable...

_Originally posted by @aphillips in https://github.com/unicode-org/message-format-wg/pull/511#discussion_r1383569393_ I think it has to work that way. I don't think "eager" evaluation is necessarily to a string. It is to a "formattable". Otherwise...

> The key to implementing is that: > > * The formatting is done with the offset applied. > * The matching is done depending on the type of key:...

> I agree that the purpose of the registry data (as I've described it elsewhere) is to inform tools and such about available variant keys, but _not_ to replicate either...

> Could we also reorganise the design docs a bit? Right now they're all next to each other under `exploration/`, which isn't really obvious, and makes it a bit hard...

> I find that git is actually pretty great with renames/moves. Is there some specific way in which it's bad for you? Actually, I just checked and it looks like...