The SQL standards considerations seem worth thinking about, too. We've certainly gone through a lot of pain working toward eliminating => as an operator name, and if the SQL standard has commandeered -> for some purpose or other, I'd really rather not add to the headaches involved should we ever decide to reclaim it.
OK, but I'd like to know what is going to be safe. There's no way to future-proof the language. I'm quite prepared to replace -> with something else, and if I do then ->> will need to be adjusted accordingly, I think.
My suggestion would be ~> and ~>>. I know David Wheeler didn't like that on the ground that some fonts elevate ~ rather than aligning it in the middle as most monospaced fonts do, but I'm tempted just to say "then use a different font." Other possibilities that come to mind are +> and +>>, although I think they're less attractive. But I'll be guided by the consensus, assuming there is one ;-)
As a user I would be much in favor of just functions and no additional operators if the sole difference is syntactical. I think custom operators are much harder to remember than function names (assuming reasonably well chosen function names).
Now Robert seems to suggest that there will also be speed / planner difference which seems sad (I would have expected operators to be just syntactical sugar for specially named functions and once we are past the parser there should be no difference).