And they give root access to the device along with GPL compliance statements, allowing for a flourishing developer community that creates tons of useful programs that can run on the embedded device. See for example https://github.com/reHackable/awesome-reMarkable for a list.
There is also an opkg-based package manager and repo with many packages: https://toltec-dev.org/
Especially: Write down your root password and DO NOT factory reset the device if you want to go back to the original state.
If you follow these steps and you know a bit about linux you'll be fine.
Factory reset on the rM2 will mess with the community framebuffer service and reset your root password, effectively locking you out unless you go the fiddly way over the external port.
The rM1 is very resilient as you can directly access the internal storage without special tools.
Remarkable 2 requires a bit of parts and possibly soldering (but not required, just might make things easier if you don't have pogo pins with handles available).
Both are fully recoverable unless you do something really impressive.
Physically breaking the hardware through software, for example. I believe there's some fun possible in most embedded designs like the one used in RM1/RM2. Like manipulating power management circuitry, or maybe forcing overheat with disabled throttling, and the like.
If this e-ink device is usable as a secondary display for my laptop, I'm in.
I'd love to get work done in sunny locations, like gardens. But these LCD screens make me squint. e-ink would be THE solution to this, but the e-ink displays are too expensive, to well supported and not very big.
In the rM1 you just write to a framebuffer device in /dev/fb0 to write on the screen. It's so easy you could probably write an application that does that, compile it for ARM, load it via scp and run it. All in 15 minutes even if you know nothing about the Remarkable itself.
The rM2 is a lot trickier. A full reverse engineering of the drawing routines is still unfinished, as far as I know. So you either manipulate the memory of their closed source application or reuse big binary chunks of it. There are of course abstraction layers built over that by the community but as of today I believe it's much less refreshing than the rM1.
The rM1 used the chip electrophoretic display controller directly , while the rM2 has a software controller which is closed source. Hence much of the complications
There is also an opkg-based package manager and repo with many packages: https://toltec-dev.org/