The naming bit:
Nothing final about it. But I feel its better to have actual code to discuss rather than just theory. And sorry about the messy patch, I just did a diff and output it to a file without actually reading it. And its the first time I have made a patch.
I am also not certain about the output of escape and more strings that happens in render, so someone a bit more knowledgable needs to look into that. I also could not figure out the jjt code for where to alter to affext the ASTReference, but I am sure others will be able to.
For usage, we intended to use it in a project where we have a tree of objects, each object has its own associated template. Currently we will have to use toString on every level, and no context information can be inherited. With this we could better control how objects where written to the Writer, reuse the same writer instead of creating alot of strings, and inherit the Context. And another argument is that is always nice to be able to plug in to core mechanics of a framework to make it more flexible in use, as long as this is not hackish.
Some other suggestions some work colleagues suggested was to have some core-interceptors for for example String and NULL, so this system is used for everything (and it is now possible to override null and String).
Another core feature would be to add a Renderable interface with just the method render(Writer, Context), and an interceptor that just called the render method. This way you could use this without having to alter the default configuration.
I am not sure if I like the List<Class> supports() though, as it won't be possible to pick up on interfaces and subclasses correctly then. It could be changed to isClassSupported(Class) rather than isObjectSupported(Object), so you would dissalow reading of instance properties to determine if an Object can be rendered.