1) Are your binding commands immutable?
2) My difficult is managing the binding commands. Say I have 2 drawables with different materials, each material have different shaders with different cbuffers layout (consider different slots usage only..).
2.a) bind view projection cbuffer (needs current shader slot info)
2.b) bind textures (needs its shader slot info)
3) I cant hold binding commands for none of these groups (except the material group), because they change depending on the current shader/material bound.

1) Yes.

2) I choose to simply be explicit with my cbuffer slot assignments. e.g. across different shaders that will be used in the same stage in the same way (e.g. opaque/gbuffer rendering), I'll choose to assign their camera cbuffer always to slot #1. I do this by defining the camera cbuffer in a header (which contains the register HLSL keyword), which is included into the various shaders.

2.a) If you've got the ability to enforce that every 'camera' cbuffer contains the same layout across shaders, then you've also got the ability to enforce the same register numbering scheme across shaders.
2.b) The textures that need to be bound and the shader that will be used by a material are both known at data-build-time, so assuming that the material is immutable, then there's no issue there.

[edit] if it's a runtime generated texture, (for post processing, or a deferred shadow mask in a forward renderer, etc), then I do the same thing as (2.a) -- I enforce that every shader specifies this texture binding on the same slot/register number, so that the same binding command can be used across shaders [/edit]

3) If I were to support that case, then the cbuffer binding command would contain a string and a cbuffer data pointer, and the string would be converted to a slot# at draw-time. This is pretty inefficient though, so I don't do this and instead do the above.

If you're in OpenGL land, cbuffers are called UBOs (a buffer object that holds uniforms).

State group is specific to Hodgman rendering system, it refers to a list of "pipeline states setters", commands that set things like cbuffers, blend state, shaders, texture..etc

Also, in D3D9/10, there are API level "state blocks", which are similar (a container for certain Set<State> commands), but I don't use these

Cbuffers are sm4.0+ only aren't they? Meaning DX10+?

If data is being generated by the engine and then input into a shader, then yes, the shader and the engine need to agree upon the layout of that data.

For a simple object, this might be some standard cbuffer that just contains a 'world' matrix - this is basically the objects 'render transform component'. For an animated object it might be a cbuffer containing an array of bone matrices.

You might have another standardized cbuffer that contains the view-proj matrix that's owned by the camera, etc.

Not every cbuffer layout needs to be standardized like this, just ones that contain data that's generated by the engine, like matrices.

Often material settings (colours, texture scales, etc) can be set just once, by looking up a variables location within a cbuffer by name. In my engine, I build these kinds of material cbuffers offline using a tool (which reads the values from an artist's DAE file, and matches them up with the cbuffer layout written in the shader code), but you can also do this at runtime when necessary.