Oh my, so you can have two symbols that have the same string representation yet are not eq? Symbols are not just plain strings? Oh my, oh my, I'm definitely going to have to sleep on this one.
Yes. Strings are read by the reader and depending on (readtable-case *readtable*), the reader try to find the symbol in a package (if specified, or default), and if not found, it will create a symbol which is interned in that package (if not specified). Fresh, uninterned symbols can be made using (make-symbol string), and they should be regarded as a new object that just happens to have a field which contains the string. Symbols having the same name within the same package are eq because the reader will just find the same symbol (or you would find the same symbol, if you searched directly in the package):
CL-USER> (eq '#:test '#:test)
NIL
CL-USER> (eq '#:test (make-symbol "test"))
NIL
CL-USER> (eq 'test 'test)
T
I'm merely a poor disoriented soul trying to reconcile lexical/dynamic(/global?) scope and environments in a way that will allow writing in some form of module system later on, if (?) necessary.
I probably put too much stuff in that post. CL does let you control whatever you want, but that doesn't always make for a simple language. Most languages tend to opt for less.
Dynamic vs lexical scope isn't too difficult, but it can be a bit confusing because the same forms are used to handle both, despite them being very different internally (as to how they are implemented). I've even seen people advocate using different form names so as to not confuse newcomers. Dynamic scope works like a (thread-local) stack which pushes a new value each time you bind something to the 'special' (name) variable to some value, and pops it when it goes out of the scope of the binding form (it will also obey all non-local transfers of control-flow, such as conditions, among others).
Whenever you access or set the value of some dynamicly bound variable, you act on the top of the variable's stack (which encompasses the entire thread or process, if not multi-threaded). It tends to be useful as far as parametrizing code goes, but it's not really meant as a 'global' in the way you use globals in C (despite that you could use it like that if you never bound it and just set it). CL doesn't support globals, but implementations do, and you can portably implement them if you want using symbol macros - I can't say I ever needed 'pure' globals, most of the time I actually wanted dynamic variables.
While dynamic scope affects all the functions that are called (if you want to access some dynamicly scoped variable), lexical scope is the default and any normal variable is lexically scoped, that is, a variable will be accessible within the textual scope where it was defined - it's also possible to shadow lexical variables, but this shouldn't be seen as anything more than a convenient trick as the compiler/interpreter would just rename each variable and even if you used the same name for 2 lexically scoped variables, they'd be different ones (and the compiler/interpreter knows it), in the sense:
>(let ((x 1))
(print x)
(let ((x 2))
(print x)
(setf x 3))
(print x))
Lexical scope isn't completly trivial though, you can also have closures, either on lambda's that are returned, on local functions, or even as a wrapper around an entire top-level function - almost anything goes, as long as the variable is visible lexically.
Back to the module system: I don't know what the goals of your language are - there's so many options and it's really about trade-offs between simplicity and flexibility/features. CL is very flexible, but it can get a bit hairy at times, while some other languages have simpler systems, but don't always tweaking that one special thing that you might want.