Another loose point I found in this article, which possibly leads to a wrong understanding:
Here is my test query:
DECLARE @a TABLE (a varchar(20) NOT NULL)
DECLARE @b-2 TABLE (b varchar(20) NOT NULL UNIQUE)
INSERT @a VALUES ('a')
INSERT @a VALUES (1)
INSERT @b-2 VALUES (1)
INSERT @a VALUES (3)
INSERT @b-2 VALUES (3)
INSERT @a VALUES (5)
INSERT @b-2 VALUES (5)
INSERT @a VALUES (7)
INSERT @b-2 VALUES (7)
SELECT TOP 2 *
FROM @a A
JOIN @b-2 B ON B.b = A.a
Now, we get back 2 rows, but how many times insex seek on @b-2 is executed?
Answer is 3.
But there are 4 matches, and only 2 rows are required.
So, why 3?
Because 1st seek for 'a' does not bring any result and is eliminated by JOIN (Nested Loop).
So, TOP contunues to request rows until it's fed up.
As soon as 2 rows have successfully passed JOIN and reached the TOP it stops the execution.
But it cannot happen until the rows are actually submitted upstairs by Scan, Seek and Loop.
This example clearly shows that execution of TOP is dependant of the outcome of Loop, which is dependant on the outcome of Scan and Seek.
It just cannot do its job until Scan and Seek have completed their tasks and physically submitted the sufficient number of rows to the buffer.
That's why it's totally wrong to say that operator TOP executes first.
If you wish, parts of it, some "Open" and "Init" statements.
But the operator as a whole executes last, as it may do what it's told to do only after other operators supplied some data to it (which means been executed, if I'm not mistaken).
I think the question as it was asked is totally misleading.
It should be about priority of control, not about order of execution.