Group chats and just about everything else messaging clients have supported for a decade are part of the Universal Profile that came out nine years ago (file sharing, location sharing, audio messages, etc., although Signal still lacks location sharing so I guess RCS is still ahead of the curve here). These features will not always fall back well to SMS/MMS, though, according to the spec: https://www.gsma.com/solutions-and-impact/technologies/netwo...
Synchronisation is not part of the problem it's trying to solve (sending messages between devices), the same way SMS and MMS don't, so that's up to the apps implementing the protocol.
E2EE has been added very recently (https://www.gsma.com/solutions-and-impact/technologies/netwo... came out a few months ago), and post-quantum encryption is still being developed. It uses standard MLS (RFC 9420) for messaging, so verification will have to be implemented however normal MLS implementations do it. I don't know if there's a standardised way to do it, I haven't fully read the most recent RCS spec yet.
I oversimplified RCS somewhat, it's not just HTTP wrapped in carrier stuff. It's also SIP, SDP, XML, OIDC, RTP, and JSON wrapped in carrier stuff. Still, page 428 of the second link shows an example of a POST request that you can make after combining all of the tidbits of specification that came before it, and that's where the simple JSON+XML shine through the stack of protocols that are tasked with delivering it. The E2EE layer is basically just sending base64'd encrypted messages over that same interface.
The protocol makes sure a message sent from one phone/tablet/watch makes it to the other end. If you want to synchronise that message between your devices, you'll have to build that locally.
Apple, Google, and Samsung can synchronize SMS messages through their cloud services, so the same also goes for RCS. For more privacy-oriented folk, KDE Connect can also offer SMS messaging to the desktop by synchronising locally with a connected phone.
