Core architecture abstraction deficiencies

I have been poking around Drupal core for various reasons, and I think that there is a missing abstraction: Drupal has input type, which is related but doesn't seem to be factored quite right. Let me explain how I got here and why I think this is a deficiency.

I started poking because I hit three bugs in rapid succession:

• Core image module would not permit SVG upload, even though imagemagick toolkit can handle them. The restriction PNG/JPG/GIF is hard coded inside the core image module. This makes sense (up to a point) as an output format restriction. The input format restriction should properly be "any X that can be rendered to one of PNG/JPG/GIF in the desired resolution at the desired size.".
• FCKEditor (and others) tried to take over on a document whose input type was XML.
• There is no obvious way to specify independent processing chains for distinct input types. I don't want XML processing done on HTML, I don't want autolinking done on JPG, and so forth.

After a while, I realized that there is a common thread to these three problems. What we want here is a generalized model of a processing chain driven by an input type. The input type should include a notion of content model. FCKEditor would then be able to say "I should appear only if content model is html".

We then want to be able to specify filters (which are misnamed - they are content transformers) by saying "to get from content type X to content type Y, apply the following transforms in the following order". At present there is a single filter chain, which isn't flexible enough to handle multiple forms of input. To get to PDF, plain text, and so forth, we set up different content processing chains.

Finally, we want to say, in goal-driven style: "the target content types that we want for display are HTML and {PNG, GIF, JPG}" or some such. We would then look at the inputs, figure out which transform chains to run, pick the "best" transform chain (probably by weight of some sort) where there is more than one, and run the transform chain.

The problem in image.core is that instead of letting me teach it how to transform (say) SVG to JPG by supplying a transformer product, it tells me that I can only have one size. Aside: it also has the imageinfo query model for sizing backwards -- it wants to say "here is the size I want, can you produce that?" Native size should come back as an optional part of the response.

These thoughts are probably not very well organized. Some of these issues may already be addressed. I may not have the right approach. This may be a problem of missing documentation (though the hard-coding in core image module was a problem). Mostly, I wanted to raise a provocative question in case it stimulated a useful line of thought for the core team.