Ron:
Have had some reflections on what we arre doing with the CSN bit and have come
to the conclusion that that is not very clever. The reflections are:
1.  CSN is a two function bit (a) to indicate the NILfreeness of a row for
reasons of efficiency iin conversion (b) to prevent some lower function from
putting a NIL into a row that is being depended on for NILfreeness (e.g. by a
sysfn)
2.  Of these, I have decided that the second is a very funny objective. It is
a specia;l case extension of the declarative mechjanism into aggregates - in
particluar to deal with the SETQ problem for aggregates - to wit that changiung
an element of an aggegate may be done by any function to which that aggreghate is 
passed. Buty why all the hoopla about NILs? After all, there is nothing to prtevent
a fn from taking a pristine rowint as an arg and changing its type!! (presumeably
a much more drastic change), so why worry about NILs? In any case, if they are so
important, why not have a check for NILfreeness built into the type test for
rowint, so that when the rowint (now buggered) is returned from the lower function,
it will run afoul of some function that is depending on it being a rowint or some
declaration or check within its own lexical scope? Presumeably one day we will
generalize our setq checks to check the values of all objects that are passed into
functions when those functions return, or (more locally) put a checkvalue around
the third arg of any setrelt in the scope of the declaration of the rowint.
3.  For all these reasons, I favor heaving the CAN from CANSETRNIL, and treating
NILfreeness like any other declarative attribute.
4.  Ergo, we have a  property of an row (note that this property is of no concern
to an array, which is whi I was so adamant about not attaching it to alloc.sarray)
which may be either a function or a selector (i.e. either F(X) or X:F) called
WATCH-OUT-FOR-NILP which is NIL only if there is no NIL in the row (note the
direction of the logic). One way to implement this is as a function which scans
the elements  (in which case the "only if" above is "iff"). Another way is to have
anyone who puts a NIL in turn out the WAFN bit and have the elts serahced (to
provide a defiunite answer - which is needed oinly for CONV.ROWINT and (type? 
ROWINT) ewxpressions) iff that bit is on. [read "on"for "out" in "turn out"].
5.  To implement this we need to rename the CSN bit, make sure that both SETAELT
and SETRELT turn it on when storing NIL (this involves changing SETAELT), but I
think that in many of these cases we cancompile this out of the final version,
and modifing the ROWINT functions torequire (and WAFN search) instead of ~CSN.
Note that the serach is done only in type expressions (rare in the compilenodebug
system) or conv.rowints (where they are necessary anyway) and then only if
someine has actually stired in a NIL (also rare). Once again, I think we can
statically remove most of those that are left when we turn the screws on the
optimizer. [Furthermore, note that the search is always going to produce a break
(or uerror) except in the extremely rare case of someone storing a NIL in and
then over writing it with good data. But currently we cant even do that computation
(as we observed to our grief in CROSS]
6.  The costs of this scheme? One cannot be absolutely certain that a constructed
rowint will remain a rowint forever. But, as suggested baove this was never for
sure because of other fields (and in general is never sure for aggregates) and
I doubt thst such a changed row would go undetected for long anyway.
7.  Ergo, I'm for making these changes. Think it over, and do them if you concur.
Beau
PS: If you agree, why not clean this up and make it a design memo? Else I will.