Lutz was correct is saying that the behaviour of the examples is caused by the behaviour of sql predicates involving nulls rather than outer join, as was his description of outer join. Likewise, Bob's observation that the WHERE clause is always *conceptually* applied after the evaluation of the FROM clause (and to each row returned by the FROM clause).
IMHO, understanding both these concepts is fundamental to understanding the way in which sql works. The latter (order of eveluation) is particularly important when understanding any sql statement with a WHERE clause contains nested subqueries.
In Steve's original example, where he wanted rows with a null orderplacedate, the correct thing to have done, as pointed out by Yelena was to write the WHERE clause as:
WHERE datepart(m, o.orderplacedate) = 10 or o.orderplacedate is NULL
Returning to Lutz's explanation of (left) outer join, for those that speak sql better than english:
select A.id, B.id
from A left outer join B
on a.id = b.id and b.id <> 8
is the same as:
select A.id, B.id from A inner join B on a.id = b.id and b.id <> 8
select A1.id, Null from A A1
where not exists( select A.id, B.id
from A inner join B on a.id = b.id
and b.id <> 8
where A.id = A1.id)
Of course, before the '92 sql standard introduced outer join, we always had to resort to doing it the long way.