I have had a major headache while using MSM eUML state transition tables, thankfully I've found a simple solution.
First MSM and especially eUML are great, and that's why I persevered to find a solution.

Here's the problem:

Declaring a complex eUML state transition table may result in the compiler generating an error.

BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((
// row_1,
// row_2,
// ...
// row_a,
// row_b,
// row_c,
// 
// Eventually the Microsoft compiler VS2008,2010,2012,2015 will all explode with fatal C1202: recursive type or function dependency context too complex
), transition_table ); 

I haven't tried with gcc.

The solution is to break the state table in two smaller parts rather than one big table:

BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((
// row_1,
// row_2,
// ...
), transition_table_part_1 ); 

BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE((
// row_a,
// row_b,
// row_c
), transition_table_part_2 ); 

typedef boost::mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table;  // No error, even though it contains just as many rows


[Waffle warning] I think that what's happening is that once the compiler has fully described the transition_table_part1 it unwinds what it is doing, it is able to unwind and 'bank' transition_table_part1 as just being a type in it's memory, and when it comes to generate transition_table via boost::mpl::join_view it just constructing the resulting type list from two sets of previously 'banked' types. This is I think why I can still nest a sub-state machine which is on the limit of the complexity of state transition table it can contain; even though nesting state machines recursively references state transition tables.

Things that did not work: [ more waffle ] There are some other solutions that I tried before I had the Eureka moment.  One was to try to hide a sub-state machine within a concrete class but that didn't work because the outer fsm needs to see the inner stt. Another way was to implement a sub-state machine as a concrete state (not fsm), and then add a process_event method on the class which delegated to a member fsm which was hidden from the outer fsm, I got this to work, but it did not solve the problem, and I had to abandon use of exit_pt_, although it may have brought down compile times.

Another helpful advantage of this solution is that the memory required by the compiler is significantly reduced.


Christophe:
Would you consider adding the example above to the MSM documentation, I would suggest under:
    Chapter 4, Compilers / Performance, Compilers Corner

Also under: 
    Chapter 5, Questions Answers and Tips:

    Question: Why do I get "fatal C1202: recursive type or function dependency context too complex"
    Answer: Likely because a state transition table has become two complex. Split the state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts.

     Question: Why does my compiler generate a fatal out of memory fatal error.
     Answer: Likely because a state transition table has become two complex. Try and split the most complex state transition table into two parts, and then use typedef mpl::joint_view< transition_table_part_1, transition_table_part_2 > transition_table to join the two parts.


- Mark Bartosik