It seems Red faced a need to represent floating point coordinates. But they believed supporting this in PAIR! would make it unreadable, e.g. 2343.122x54239.44. To address this, they added a distinct type called POINT!:
Red Programming Language: Subpixel GUI
Their choice for representing points uses commas inside of parentheses, and can extend to any number of coordinates:
(2343.122, 54239.44)
(2343.122, 54239.44, 6309.332)
(2343.122, 54239.44, 6309.332, 442.3321)
(2.33487e9, 54239.44)
(2.33487e9, 54239.44, 9.83242e17)
(2.33487e9, 54239.44, 9.83242e17, 5223.112)
(1.#inf, 1.#inf, 1.#inf)
They observe this means they no longer support commas as decimal separators:
"Such literal forms requires the comma character to be a delimiter, so that it cannot be used anymore as a decimal separator. That was, unfortunately, a necessary decision in order to unlock such literal forms. The gains should be bigger than the loss."
Despite Ren-C's very different usage of COMMA!, I actually never killed off commas as decimal separators...so if you don't put a space after a comma, you get very different behavior:
>> length of [1, 2]
== 3
>> second [1, 2]
== ,
>> length of [1,2]
== 1
>> first [1,2]
== 1.2
Technically speaking, they wouldn't have to drop it either... so long as they were willing to eliminate the idea that 1, was an alternative representation of 1.0. Ren-C drops this general equivalence not just for commas but for periods as well--and in fact 1. is a TUPLE! (whose second element is BLANK!) while 1.0 is a DECIMAL!
(But I'd certainly shed no tears if commas as decimal representations were thrown out.)
I'm Confident Ren-C's COMMA! is the Better Design
In source dialects, you can still have slots where a GROUP! containing numbers separated by commas denotes a coordinate. But you'd have to go through some step to get a runtime object that had methods. Some pseudocode for that reality:
>> data: [(1.2, 3.4) (5.6, 7.8)]
>> data.1 + data.2
** Error: GROUP! does not support ADD operation
>> p1: make point! first data
== #[point! 1.2 3.4] ; or some methodized rendering
>> p2: make point! second data
== #[point! 5.6 7.8]
>> p3: p1 + p2
== #[point! 6.8 11.2]
>> to group! p3 ; imagine TO as being methodized as well
== (6.8, 11.2)
There's so much more freedom in how you can use COMMA! as a generic part in dialects. And the consistency that if you see (...) you know you have a GROUP! is much more comforting.
But back to the original post topic: Red still doesn't have floating point PAIR!, so I feel no qualms about having gotten rid of it.