I beg to differ, currently MessageFormat is being abused for something it is not intended for under the veil of uninformed "intent" of StringResourceModel.
Contrary to what you say, arguments to a format string are not application code; they should not contain any sort of syntax whatsoever. Review MessageFormat's documentation for a description of its purpose which is clearly targeted at generating a string based off of a format string and data arguments that is to be displayed to the end-user.
I am very well aware that StringResourceModel currently considers its arguments as "application code" in the sense that it considers their contents to be of the same context as that of the localization value. I also understand there are alternative safe methods of approaching this problem. My argument, however, is against the sanity behind the existing API of StringResourceModel. I am yet to learn of any argument for the way things are now, and I have given you plenty against - which I have not seen you dispute. That alone should be enough to revert this bug to an Open state unless you can provide solid arguments as to why my impression of format arguments is so very wrong.
As for Igor's take on things; you seem to be missing the context of it all. Contrary to what you say, my request is very much to NOT escape user data in any form while it resides within the application. Escaping of data is not something that should be done by a developer as he introduces his data into a certain context - rather that context should be fit to take the data the developer offers him without allowing it to be evaluated as application code by doing any necessary escaping itself, in ITS context and syntax.
Similarly, "escaping single quotes in case you decide to build an SQL statement" is a fine example of introducing a form of "escaping" in application data. It is as rediculus as you make it out to be since it would be escaping data outside of the context of what you're escaping it for. At the same time, it is actually pretty close to what you're asking wicket developers to do now just before sending their data to StringResourceModel; escaping their own data outside of the context of property model expressions.
I think if you want to make an analogy; more fitting would be comparing this to new Label("id", "foo"); where foo is actually escaped by default by the framework. As such; consistency dictates the developer can expect the same to happen for when he passes his "foo" to the framework as data elsewhere.
No, StringResourceModel should NOT allow or feature code injection, because the very purpose of format strings is to cleanly and safely introduce arguments into application code, rather than inject them into it.