Another point is that it is impossible to implement opengl-style bindless textures on top of mantle's descriptor sets. But the AMD hardware can do it for sure because otherwise AMD's opengl drivers wouldn't support this extension.
This means that, despite the mantle's claim to be close to the hardware, it doesn't actually expose the full real hardware capabilities.
In fact the dsets in mantle are in a sense more restrictive even than the traditional APIs like opengl (without bindless textures) and d3d9, where binding a texture or a buffer is as changing any other state.
I seems that the idea behind the API design of the dsets is that the application will have a full prior knowledge about when and what textures will be used, and will somehow be able to organize the texture/buffer bindings in desc sets in advance and keep them static most of the time. Even when this is possible to do, it may be very hard, but sometimes it is not possible. For example if you are implementing d3d9 or opengl emulator over mantle you know nothing about when the application plans to use which texture/buffer, and you have no choice but to use the above described "sliding-window" with the great redundancy.
Enough talk about the dsets, now I would like to make a comment about another part of Mantle.
It's the state objects (rast, blend, samplers, msaa, depth-stencil, vport). From the point of view of the applications it would be much more convenient if we didn't have state objects. Instead of having a command that takes as parameter a state object to be bound, to have a command that takes a struct with the actual values of the states. Having objects is a burden because they need to be managed. In particular, even if creating of a new state object is lightweight, you can't just create a new state object with the current state values, draw with it and then delete it and be done with it because it can't be deleted until you know the command buffer that is using it have been fully executed. So you need to implement some kind of life-time tracking for the state objects. Alternatively you can organize a cache for them and reuse them. In any case they are nuisance.
Now I don't know how it is from the point of view of the driver/hardware. If the hardware just needs a data packet with the (probably altered) state values then please consider getting rid of the parasitic objects. (I say parasitic because they just impose a pointless burden for no benefit, both for the application and for the driver). But if they do represent some real hardware thing, then i guess we will have to cope with them.
Make no mistake, the dx11-style object-based state management is NOT application friendly. In practice the game engines seldom need to change ALL the states that are in some of the packets at once. They usually change a state or two from one packet and a state or two from another packet. The API-imposed grouping of the states in packets is practically random and non-useful from the POV of the application. So in order to deal with the state objects, they just implement a caching layer that provides opengl/d3d9-style state model on top of the object-based API. Now if the API does group the states in packets but at least doesn't have state objects that need to be life-time-tracked, etc., that would be much better.
Again, if the object model is better for the driver and closer to the hardware then, of course, keep it. I just suspect you may have wrong impression that the dx11's model is good for the developers and so you followed it in mantle.