Internationalisation has emerged as a dependency for the REST API. There are i18n-shaped holes in several merged and WIP patches. Since we're doing everything the "right way", with minimal coupling, this ideally means injecting a message localisation service into ResponseFactory.
There was some discussion in San Antonio about introducing a constructible value class similar to MessageSpecifier. A limitation of MessageSpecifier is that unlike Message, it does not have a concept of parameter types. Message has approximately 9 parameter types: raw, num, duration, expiry, period, size, bitrate, plaintext and list. A reduced set of parameter types would help to make the message formatter interface narrower. However, it could cause difficulties if we need to convert a Message object returned by MediaWiki internals into a REST API message.
We can also look at IApiMessage as a precedent. It has getApiData() and getApiCode(), which allows the action API to provide extended error information in JSON-formatted responses.
There is the question of what language to use, or whether to support having multiple languages in a single response. The action API has the errorlang parameter, which may be "content", "uselang" (apparently a misspelling of userlang) or an actual language code. Should the injected message formatter have a concept of user and content language? If we support multiple languages in a response, we won't be able to inject a message formatter which is initialised for a single language. There will either need to be a factory class, or the formatting functions will need to have a language parameter.