Archie is correct - the question and its explanation is incorrect. The QotD feature should teach, and teaching to neglect relational principles and rely on implementation details is questionable. Yes, MS SQL (any version I've ever known back to 6.5 if I remember correctly) will output rows in clustered index order when unspecified, but no, this shouldn't factor in this context. Query 3 cannot guarantee the result will be as asked.
You are not correct. SQL Server will usually output rows in clustered index order when unspecified - but at least since SQL 7.0, maybe even before, other orders have always been possible. Check http://sqlblog.com/blogs/hugo_kornelis/archive/2006/12/31/Beatles-vs-Stones.aspx for an example.
Other (less amusing, but probably more common) reasons for getting a different order include:
* Parallellism. Run a big query against a large table on a system with multiple processors, and you'll often see jumps in the range. Order is not preserved when gathering the parallel streams, unless requested.
* "Piggyback scan". Quite rare, and Enterprise Edition only - this feature allows a scan of a table or index to get rows from another scan that is already processing, then restart at the start until it reaches the point where it started piggybacking. If no parallellism is involved, this feature would show in the output as results starting somewhere halfway in the table, continuing in order of the index being scanned until the end, and then starting fro the beginning until the starting point of the results. (So when an index on an integer is used, you'd get results from 12,659, 12,660, ... until the maximum, then 1, 2, ..., 12,658)
* IAM scan. Also rare, because it requires either read uncommitted isolation level (which should be much less common that it actually is) or a full table lock (which is exactly asa rare *** it should be). If a table is large enough and the locking requirement is met, an IAM scan will scan pages in physical allocation order instead of their logical order.