So, you could use the "sugared" syntax, and revert to the isomorphic (that's the world?) sexpression syntax when you want to do s-expressy stuff like macros etc.
Of course you'd have to keep in your head the mapping between the sugary and sexpressions version, but it's not that difficult, and you'd only need to do that if you wanted to use sexpressions, not all the time when you don't really need them.
It's possible that you could create another syntax. But there are some challenges to deal with:
1) The presence of macros. I can extend the language with new syntax however I please. If you just write a parser, the minute I do so, it's going to be very difficult for that parser to determine the order of operations. It has to have some general solution to the problem of precedence.
2) It... I suspect... has to be homoiconic. That is the underlying datastructure that the code corresponds to has to be immediately visible to the human coding. When you write programs that manipulate programs, the lack of this ability cripples you.
If new programmers learn ... what I suppose you might call a cleaner syntax ... and then have to switch into sexpressions to see what's going on, I don't much rate their chances of learning Macros - they'd essentially be learning a new language when they got to the point where they'd want to do that.
3) It has to be mappable - and preferably in a reverse compatible way - to, if not all, the vast majority of existing Lisp code, (otherwise people who are already comfortable with Lisp code won't have much incentive to use it.)
#
I'm not going to say that's not possible. What I will say is that a fair number of people, who I don't think are idiots, have tried to update Lisp syntax in the past. Among others attempts RLisp, Dylan, and IACL2. I'm not aware of any project that's managed to maintain the ability of Lisp to clearly manipulate programs as data and to swap back and forth between interpreted and non-interpreted code.
But it's possible they just couldn't see the problem as clearly as we could because they couldn't see that the approaches they tried were going to fail. If you can think of a syntax that solves things, I'd read up on past attempts to see if someone's tried it before and then give it a go. Writing your own reader can be a bit of a pain, but it's probably more doable in Lisp than any other language I can think of. :)
So, you could use the "sugared" syntax, and revert to the isomorphic (that's the world?) sexpression syntax when you want to do s-expressy stuff like macros etc.
Of course you'd have to keep in your head the mapping between the sugary and sexpressions version, but it's not that difficult, and you'd only need to do that if you wanted to use sexpressions, not all the time when you don't really need them.