There is no apparent pattern.  But, I think this is irrelevant anyway.  If
you have a table and a query each of which provide the _exact_ same
resulting dataset when you view them, you would expect a 2nd query that
looks at the source table or query to produce the exact same results.

To try to be a little more concrete:

Query1 : A complex query with inner and outer joins of queries and tables.

Table1 :  This is produced by running "SELECT * INTO [Table1] FROM [Query1]"

If I run "SELECT * FROM [Query1]" or 'SELECT * FROM [Table1]", I get the
_exact_ same result set.  So far everything is fine.  But here's where it
gets interesting:

Query2a :

SELECT
 q1a.ID, q1a.someDate,
 Max(IIF(qa2.ID > qa1.ID, q1b.someDate, Null)) AS NextDate
FROM
 [Query1] q1a
 LEFT JOIN [Query1] q1b ON
   ((q1a.ID <> q1b.ID) AND (q1a.CLNTID = q1b.CLNTID))
GROUP BY
 q1a.ID, q1a.someDate

Query2b :

SELECT
 q1a.ID, q1a.someDate,
 Max(IIF(qa2.ID > qa1.ID, q1b.someDate, Null)) AS NextDate
FROM
 [Table1] q1a
 LEFT JOIN [Table1] q1b ON
   ((q1a.ID <> q1b.ID) AND (q1a.CLNTID = q1b.CLNTID))
GROUP BY
 q1a.ID, q1a.someDate

Notice that Query2a and Query2b are identical, except that one uses Query1
for it's source data, and the other uses Table1.  (But remember Query1 and
Table1 return the _exact_ same result set).

Query2a will return about 26 records, and Query2b will return about 400.
Query2a and Query2b should be returning the same result set.  It's like
Access is trying to do some optimization when querying a query, but it's
getting it wrong.  If Query2a is too complex (because it involves queries of
queries of queries), then I should get a "too complex..." error.

As explained in my other response to your question, I can't see any pattern
(I looked for patterns of particular values or nulls in columns, but I can't
see anything).  Also, I still think this is irrelevant.  I have [Query2]
that examines some data.  Whether that source data is coming from another
query or a table, as long as the source query or table contain the exact
same result set (and they do), [Query2] should give me the exact same
result, but it doesn't.

I have made an interesting discovery though...

[Query2] references [Query1] and [Query2] is not returning a lot of records
that it should (I've already established this).

[Query1] includes the 'DISTINCT' clause so it contains no duplicate records.
[Query1] references [QueryX].  Now, [QueryX] does not contain a 'DISTINCT'
clause and does have some duplicates.  When I add the 'DISTINCT' clause to
[QueryX], the duplicates are dropped.  However, the output of [Query1]
remains the same since the 'DISTINCT' clause in [Query1] was already dealing
with any duplicates from [QueryX].  So to recap, [Query1] has the same
output (no duplicates) regardless of whether or not [QueryX] has duplicates.

But here's the funny part.  [Query2] does produce the correct output when
[QueryX] includes the 'DISTINCT' clause.  This is strange, since [Query2]
has no direct knowledge of [QueryX].  [Query2] only references [Query1].
It's [Query1] that in turn references [QueryX].  As I've already explained,
the result set returned by [Query1] is identical, regardless of whether or
not [QueryX] returns duplicates (becuase [Query1] always has a 'DISTINCT'
clause to remove duplicates).

It really seems that when you run a query of a query of a query etc., Access
doesn't run each one in series, but rather tries to do some
behind-the-scenes optimization.  Unfortunately, it doesn't seem to be doing
it correctly in all cases.  If it can't correctly optimize a long chain of
queries, then it should give me an error, rather than a result set that's
just missing some records.