Isn’t this the way C++ operates under the hood, with the “this” pointer hidden?

I love opaque structures, but the one downside in embedded is they can’t be truly opaque since you want to avoid dynamic memory allocation - and therefore the place you instantiate the struct needs to know the size, and therefore members of the struct.

This might sound stupid but I have ONLY ever known OOP in the Ruby / C++ / Java sense before but this idea blew my mind as such an interesting and different way of thinking about it and I can't tell if it is just my own bias but my initial thought is that it seems like such an additional level of mental overhead that you would always have to carry around on top of everything else you already have to think about. I assume that becomes easy with time?

It's the opposite - you can spend less time worrying about the details because you know they're opaque. It's like how in Java it can actually be easier to work on a generic datastructure (e.g. a tree) than a more concrete implementation (e.g. a tree of integers) - the generics force you to cleanly separate the structure-specific parts and the value-specific parts and not get them mixed up.

You can achieve the same kind of hiding in Java by using an existential type. E.g. you could have a library that looked like:

    interface Cursor<T> {
      T start();
      T nextStep(T currentState, int move);
      void finish(T);
    }
    class DataStructure {
      Cursor<?> traverse();
    }

And then you don't know what the internal state of the cursor is because the T type is hidden from you, but the compiler checks that you always call nextStep() with the same state you got back from start(), and you can't possibly mix up the state from two different cursors.

It's just an attempt to make C slightly more OOP without using C++. A very common design pattern in GNOME, for instance.