I'll get back to you on that later tonight, need to think about this some more - way late for work right now... (thanks to you!)
However, yes, I think there needs to be distinction between a standalone shader concept, and a pipeline concept, which is concerned with linking several multifunctional shaders together - your "uber-shader-backend". Lack of distinction on this point is causing all this confusion.
Cool, I'm looking forward to suggestions.
Meanwhile, I've separated the ATIFS implementation and the shader backend changes in my patches. The result is attached. The patches named "1", "2", ... will be merged together to avoid regressions due to partial implementations, and they need some reordering. I've hacked that together during my train ride, so I've no idea if it really works.
I've separated the shader model changes and the atifs implementation to make Alexandre happy. I'm now also enabling ATIFS only if ARB vertex shaders are enabled, pixel shaders not disabled, GLSL not supported and ARB_fragment_program not supported. Thus atifs only inherits from the arb backend, which avoids the 3 shader backend structures and makes dealing with the private data easier. So I think it partially addresses your concerns. atifs still has to route vertex processing through the ARB backend, but we will need that if we implement d3d pixel shaders using atifs, unless we split up vertex and fragment shader processing backends(So separating fixed function and programmable won't help there).