I think I am missing something

[HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)]

In the last couple of days, I have been seeing lots of potentially
useful discussion on how difficult it is to change various programs or
dialects to fit various conventions.  However I was also interested to
see why one would want to change from the hallowed definitions of T and
NIL in the first place. One of the messages yesterday had what seemed at
first to be a good justification, and at least one person has made
comments in passing today that seem to indicate they were thinking the
same thing.  But I have a problem with it. The justification, as I
understand it, is that currently NIL is overloaded, and thus leads to
ambiguities.  The most common one is when you say (GET 'FOO), you get
back NIL, and you don't know whether this means there is no FOO
property, or there is one and its value is NIL.  I agree that this is
annoying.  However as I understand the proposal, () is going to be used
for both the empty list and Boolean false.  If so, I don't understand
how this resolves the ambiguity.  As far as I can see, the new symbol
NIL is going to be useless, except that it will help old code such as
(RETURN NIL) to work. Basically everybody is now going to use () where
they used to use NIL. As far as I can see, the same ambiguity is going
to be there.  Under the new system, FOO is just as likely to have a
value of () as it was to have a value of NIL under the old system, so I
still can't tell what is going on if (GET 'FOO) returns ().  Even if you
separate the two functions, and have a () and a #FALSE (the canonical
object indicating falsity), something that would break *very* large
amounts of code, I would think there would be a reasonable number of
applications where properties would have Boolean values.  So (GET 'FOO)
would still sometimes return #FA