To add weight to Hugo's argument, here's a bit from BOL that seems relevant:
Caution:
If there are multiple assignment clauses in a single SELECT statement, SQL Server does not guarantee the order of evaluation of the expressions. Note that effects are only visible if there are references among the assignments.
If a SELECT statement returns more than one row and the variable references a nonscalar expression, the variable is set to the value returned for the expression in the last row of the result set. For example, in this batch @EmpIDVariable is set to the EmployeeID value of the last row returned, which is 1:
USE Northwind
GO
DECLARE @EmpIDVariable int
SELECT @EmpIDVariable = EmployeeID
FROM Employees
ORDER BY EmployeeID DESC
SELECT @EmpIDVariable
GO
Now, of course the QOD result doesn't depend on the order in which the rows are evaluated, but it does depend on all the rows being evaluated. In the BOL example, the lowest EmployeeID is placed in the variable, apparently because it's the last one evaluated by a query that examines each row in table Employees in descending order by Employee.
But what if someone at Microsoft were to improve the performance of this query by tweaking the optimizer to take advantage of an index on EmployeeID and simply return the equivalent of min(EmployeeID)? The query behavior would still meet the description in BOL, only run a bit faster.
Then, even without an "order by" clause, it may be reasonable for the query to still use the value of the last row, even if that is by rule unpredictable. That brings us back to Hugo's point, which is that it can be dangerous to depend upon undocumented behavior of a db engine. By the rules, he's right that the answer could well be 2 or 3, depending on the implementation of the documented expected results for a query in this form.