I don't like how the number of things staying "as they are right now" is growing, while the number of things being changed remains confined to render states. To have a proof-of-concept state management system, it would be best to take things that are as different as possible, and manage to get them successfully updated via the new state manager. Otherwise you won't find out whether the design is flawed or not until much later.
Agreed, in theory. But I also think that we shouldn't try to put different things in one model by force. If some things work differently, why shouldn't we handle them seperately?
Because that creates confusion and disorder - the idea is to move from chaos (gl code in drawprim, shaders, device.c) to order (gl code in one place, following a uniform pattern, with the ability to do locking and/or switch the gl backend).
Shader constants are different from fixed function things in two ways: There is a dynamic number of them,
That's only a problem, because you keep trying to force everything into a constant array :)
and there are no dependencies between 2 shader constants. So there is no use for a table like the fixed function elements,
Sure there is... it creates a uniform structure for applying states, bringing some benefits as described above. Dirty-tracking is only one of the goals, and the stateblock already does some of that..