hash-bang: seems necessary for creating shell executable scripts. this format is the standard for shell executable scripts which are important because they allow scheme programs to be used as simple commands on most systems. the syntax is one line starting with #!

• it leads the programmer to think of a low-level optimisation in the form of tedious-to-work-with, ambiguity creating syntax
• it does not enable a very useful new way of expression because everything could be specified using lists and the basic "pattern matching" that lambda application provides; concepts where a high investment in compiler optimisation is likely done because it is ubiquitous. example, passing "multiple return values" to a procedure and binding to identifiers: (apply (lambda (a b . c) #t) (list 1 2 3 4 5))
• doubles the possible syntax and semantics for result value destructuring. you have to learn call-with-values, values, let-values, the new "too few arguments" problems you will be dealing with and repeatedly rewrite one way of passing multiple values into the other, as of course you will still be working with procedures that are well applied with lists
• continuation-passing-style could be a better alternative for all cases where multiple-return-values are deemed useful. and it still keeps the many-to-one relation between arguments and result, the simplicity of which is not to be underestimated. anecdote: for example, in a automated testing library i wrote, input and expected output arguments are specified alternatingly. input arguments can be lists to specify multiple input arguments. that means input arguments that are lists always have to be wrapped in a list to designate them as a first argument without ambiguity. an analogous complication would have arisen had i implemented the same interpretation for output arguments
• the execution time when using multiple return values was 6 times longer when i tested it. now what was the reason for using them again. tested with guile 2. that it can be slower might say something about its implementation complexity
• the theoretical performance benefit is relevant when value destructuring happens often, which i have seen in mathematics related algorithms. it is questionable though, if the use of multiple-return-values in existing procedures like partition, span or list-diff+intersection can lead to an appropriate performance benefit
• in a case for mrv, what seems missing syntactically is a feature where the values are spliced into the arguments of the standard application form, like so: (proc a b (mv-producer) e). something like "apply-values" could also be useful: (apply-values (l (a b . c) (+ a b)) mv-producer)

• "car" and "cdr" are absolutely opaque words. even knowing about the etymology, coming from "contents of the address part of register number" and "contents of the decrement part of register number", does not really help to infer the meaning
• the word increases vocabulary while not really adding a distinct meaning, adding ambiguity
• "car" is about referencing the first pair element in a list, or the first list element. that is why first is a relevant name
• the next best word might be "head", but this could include to mean multiple elements, while "first" is really just about the first element of a pair or list. as a sidenote, the linux command-line tool "head" selects one or multiple elements
• "left" and "right" may be even better because they somewhat emphasize two-valuedness, and would avoid the figurative aspect of the following renaming "tail"
• the word "first" can be considered short. one could use abbreviations for it, but i would not bother, because losing the clarity obtained by using common english words is not worth it
• there is "last" in srfi-1 for lists, so "first" is the opposite end
• names are usually vague, but we should strive for keeping the vagueness low without having to invent new words. sometimes concepts are so different, a new word is appropriate. but not in this case. appeals to tradition, or arguments like that it supposedly sounds better over the phone, do not cut it

• "tail" is already a common name for its result
• the name "cdr" has the same problems as "car"
• an alternative could be "rest" for "rest of list", but rest has a broader meaning and might lead to confusion easier because of the existence of rest-arguments, and when using the word rest for "rest of something" instead of "rest of list-elements"
• as mentioned above for "first", "right" could be another viable name

• aside from there being historical or technical explanations for "cons cells" or the like, the name coming from "construct", which is too general, is not about what we specifically do when using cons
• we are creating pairs, 2-tuples with a left/first element and a right/last/second element, which as a verb is called "to pair" and is coincidentally also the word for the result
• sometimes the word "cons" is used to mean "prepend"

• like "pair" but chains the pairs with their second element
• (pairs 1 2 3) is equivalent to (pair 1 (pair 2 3))

• these are the shortest renamings. because they are only few, and fundamental syntax forms, used very often (read: in almost every code file), and the result is visible literally in the arguments, it should be acceptable to have short, opaque binding names for them. it is in any case better than special chars

'test (q test)
'(a b c) (q (a b c))
(map (lambda (e) (+ 1 e)) mylist)
(map (l (e) (+ 1 e)) mylist)

this is optional, the original "for-each" might actually be the better name. each is shorter for bindings like each-integer