you can already scale/resize images on runtime, with Opengl and SDL. It isn't very intuitive but works. The rotation thing is more complicated, as prock said, it could lead to confusions. I'm not sure if it's really worth the effort.
The batch rendering is able to work with different geometry tyes (point, line, triangle, quad,...), but textures use internally always a quad. You could create another version of addImageToArray() which internally uses triangle or triangle stripe. But in general, there should be more types, for example FIFE still missing the opportunity to render circles (filled/unfilled).
Well, lighting effects... FIFE have a LightRenderer which uses blending. You can add Images, Animations or create a light primitives (use renderbackend drawLightPrimitive()), also you can change the blending modes and add stencil buffer tests. The "downsides" are that the lights are additive and the z ordering is not right because it has its own renderer (is called after the InstanceRenderer). Rio de hola have a simple demonstration of global light and light primitives. (enable lighting in the settings and press 1/2 and 4/5)
I fully agree that shaders would be a great feature for FIFE. I had implemented a basic shader support a few years ago. But there were too many other problems so I stepped away from the idea. (those were the times in which we have used immediate rendering)
I'd hate to force users to modify config file values for all these things, we should do more auto-detection!
We do it with glee in the backends, the problem is more that (especially for ATI/AMD cards/drivers) the detection failed. The settings are meant as fallback for these cases. But of course it would make sense to query other things, such as maximum texture size, max color attachments and so on.