(1) If symbols, for example, F are used in code, but they are not in symbol-table, their value is currently initalized to NIL. I propose generalization, so the symbol F is initialized to (INIT F), where INIT is user defined function or macro - if such is defined. If not, then NIL. On that way, one can define, for example
infinitely many binary numbers b0101, b0001110, b00101010 ....
infinite family of functions car, cdr, caar, cadar, ...
I do not really know is it good or not, because it complicates the semantics of the language. However, it is already practised - for example, for representation of numbers. Otherwise, one should write something like (set '135 (decimal '1 '3 '5)), (set '0x124 (hex '1 2 4)) before using these. It begs the question - if built-in, why not user-defined as well? Finally, proposed change is not risky, because current behaviour can stay as default, and change only if one explicitly define INIT.
(2) Currently, if F0 evaluates to F1, F1 evaluates to F2, ..., F10 evaluates to (lambda(x)(x+3)) then
(F0 4)
returns an error, and I'd like it to return 7. Unlike for previous example, I am pretty sure it would be sound extension, but its harder to find example. Nevertheless, as it is to replace currently erroneous behaviour, it cannot be harmful.
Regarding (2), I just noted that original Lisp, described in McCarthy's "Recursive functions" worked on similar way (but with important differences). Here is critical part of his eval function:
eval[e; a] = (if car[e] is symbol, but not for standard functions or operators) = eval [cons [assoc [car [e]; a]; evlis [cdr [e]; a]]; a]];
Translating that M-expression to Newlisp: if some expression S cannot be evaluated directly, because the first element of S is some user-defined symbol, McCarthy's Lisp calculated (map eval S), and then tried to evaluate that.