I think Henri is generally against adding something to the ps_compiled_shader structure - but I might be wrong there.
However I don't know how to implement the code without introducing new data to ps_compiled_shader.
No, he doesn't like having this info visible outside the backend. You can certainly introduce new per-compiled-gl shader information, but it should not be 'visible' outside the respective shader backend. So in an ideal world your patchset would not touch wined3d_private.h, only glsl_shader.c, and later arb_program_shader.c, since all the NP2 fixup interfaces the backend needs are already in place.
In the past we've done a considerable amount of work to separate the shader backend implementations from the rest of the code. E.g. the ps_compile_args structure is part of that(avoids direct stateblock accesses), Henri moved parsing the D3D bytecode into the frontend(the backends operate on bytecode-independent structures), etc. The goals are an abstraction from the bytecode to enable d3d10 support, the stateblock separation allowed shader duplication, etc. However, the work is not entirely done yet,
I can implement the modification of ps_compiled_shader so you can add your data structures properly. An example of what it should more or less look like is the fragment pipeline replacement - e.g. the ATIFS specific structures are all defined in ati_fragment_shader.c, and all the frontend offers is a void * to store a pointer in the device. The question is obviously when I'll get to it, as I still have to play around with that java-jboss-whatever stuff for university.