And even then things should only be changed if they provide a net benefit; removing dot-syntax from parenscript makes one of the most common javascript idioms cumbersome and verbose. Parenscript is /not/ Common Lisp -- it is entirely acceptable for it to have slightly different syntax.
PS is a translator from Common Lisp to JavaScript. The project stopped being an s-expression syntax for JS quite a while ago.
What if there were a special form to explicitly allow a Lisp symbol through unmodified? This would be a bit different than the current |:foo| syntax (the :-escape applies to whatever portion of the split symbol it prefixes e.g. |:foo.Bar.:baaZ| -> foo.bar.baaZ).
This isn't the issue with foo.bar syntax. The problem is that putting foo.bar in Parenscript (as opposed to outside the PS compiler) fails in the presence of symbol macros for either foo or bar. Even ignoring other possible undesirable consequences, this makes it a big pain to implement 'let' with real lexical scoping efficiently or readably, and makes code inspection by conventional tools impossible. The whole issue is centered around symbol identity and the abuse of symbol names.
Prefix syntax makes method calling a bit awkward and (.method ...) syntax makes method calls a bit more CLOSish in appearance. I am neutral on its value, but since parenscript has supported this for years and a lot of code is relying on it the cost of removing it is high.
The dot syntax is a design mistake that makes what should be trivial code transformation hard. This has consequences for both the PS compiler (keeping it would make it more complicated than it needs to be) and just as importantly as for the code being compiled. If someone wants to upgrade their project to use the latest version of Parenscript, I think it's ok to ask them to fix what are essentially bugs in their code. The only regrettable thing is that these bugs were encouraged by previous versions of Parenscript as desirable programming style.
Vladimir