Here is a little example I use favor_compile_time, (see attachment)

But msm still tries to fold recursively all sub state machines states in to 1 big mpl vector.

As you said in your last mail :

...

Yes, it would work but I think I remember you mentioning boost::any not being an option. If boost::any and the performance loss are acceptable for you then it would probably help.

It would be possible to overcome this problem by using favor_compile_time but it seems apparently not :(.

It seems I didn't read correctly and thus gave an unclear answer. The problem I was talking about was the compile-time. So, if you allow, 2nd try: The favor_compile_time policy will still fold all the transitions inside a big mpl::vector, at least for the moment. I already started a new version of the policy improving this too but didn't finish it yet as the problem I was trying to improve (Jeff Flinn's exploding compile-time) went away so there was not a big demand for it. So, again, yes, the policy still makes one big vector, but it's not so much of a problem any more because the compile-times are greatly reduced by the policy. So, increasing the mpl::vector size does not hurt so much any more. Sorry for the confusion. Regards, Christophe