Description:
This problem was discovered after the fix for bug #27352, so I set "regression" tag.
See Luke Pearce's and others messages at bug #27352 for original description of the
problem.

Short explanation is: a query containing list of derived tables like

   SELECT * FROM (SELECT 1) AS t1, (SELECT 2) AS t2, (SELECT 3) AS t3, ...
                 (SELECT 32) AS t32

fails on 32bit platform (on 64bit we need t64) with a error:

  "Too high level of nesting for select"

as if we run query like SELECT * FROM (SELECT 1, (SELECT 2, (SELECT 3,...

So, FROM list can't contain more than 31 (or 63 on 64bit) derived tables.

Actually this is not a quite regression of bug #27352 fix: without that fix we may have
32/64-bitmask overflows for long lists of derived tables (as reported) containing
aggregate functions.

How to repeat:
SELECT * FROM
(SELECT 1) t1,
(SELECT 2) t2,
(SELECT 3) t3,
(SELECT 4) t4,
(SELECT 5) t5,
(SELECT 6) t6,
(SELECT 7) t7,
(SELECT 8) t8,
(SELECT 9) t9,
(SELECT 10) t10,
(SELECT 11) t11,
(SELECT 12) t12,
(SELECT 13) t13,
(SELECT 14) t14,
(SELECT 15) t15,
(SELECT 16) t16,
(SELECT 17) t17,
(SELECT 18) t18,
(SELECT 19) t19,
(SELECT 20) t20,
(SELECT 21) t21,
(SELECT 22) t22,
(SELECT 23) t23,
(SELECT 24) t24,
(SELECT 25) t25,
(SELECT 26) t26,
(SELECT 27) t27,
(SELECT 28) t28,
(SELECT 29) t29,
(SELECT 30) t30,
(SELECT 31) t31,
(SELECT 32) t32; # on 64bit platform add 32 subqueries more

Suggested fix:
sql_yacc.yy: add "Lex->nest_level--;" at the end of "select_derived" or "'('
get_select_lex select_derived union_opt ')' opt_table_alias" rule.

Thank you for a bug report. Verified just as described with 5.0.72, 5.1.30 and 6.0.7.

We have just recently updated to 5.0.79 to get around another bug in 5.0.44 and I believe
we have hit this issue with a number of queries that are used for reports.
The queries do use sub-queries, but at most there are 3 nested queries, then the sets of
queries are joined so I don't think they are nested too deep. 
On 5.0.44 they return the correct results. Please let me know if you would like some
example queries.
As this bug is going to effect our ability to update it is deemed critical for us as the
bug in 5.0.44 is causing crashing. This puts us between a rock and a hard place.
Is there any chance this is going to get fixed soon? And preferably in the 5.0 branch?

Cheers,
Jason

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/71830

2727 Gleb Shchepa	2009-04-10
      Bug #41156: List of derived tables acts like a chain of
                  mutually-nested subqueries
      
      Queries of the form
      
        SELECT * FROM (SELECT 1) AS t1,
                      (SELECT 2) AS t2,...
                      (SELECT 32) AS t32
      
      caused the "Too high level of nesting for select" error 
      as if the query has a form 
      
        SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM... 
      
      
      The table_factor parser rule has been modified to adjust
      the LEX::nest_level variable value after every derived table.
      modified:
        mysql-test/r/derived.result
        mysql-test/t/derived.test
        sql/sql_yacc.yy

Hi.
Is there any update as to what release this bug maybe fixed in?
Having to work around this limitation is really hitting our reports.

Cheers,
Jason

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/77922

2793 Gleb Shchepa	2009-07-03
      Bug #41156: List of derived tables acts like a chain of
                  mutually-nested subqueries
      
      The select_derived2 parser rule calls mysql_new_select()
      calls push_context() and nest_level++, however only
      the pop_context() was called at the end of derived table
      parsing at the table_factor rule.
      
      The table_factor parser rule has been modified to adjust
      the LEX::nest_level variable value after every derived table.
     @ mysql-test/r/derived.result
        Added test case for bug #41156.
     @ mysql-test/t/derived.test
        Added test case for bug #41156.
     @ sql/sql_yacc.yy
        Bug #41156: List of derived tables acts like a chain of
                    mutually-nested subqueries
          
        The table_factor parser rule has been modified to adjust
        the LEX::nest_level variable value after every derived table.