Hi Eduardo:
I do get this and see this is why you have not leveraged Hyperbole or Org for eev implementation. (I do feel eev has a number of interesting and useful ideas, and as I've said to you personally, I just hoped you could use Hyperbole or other existing Emacs infrastructure to avoid embedding so much code within eev).
I took a brief look today at some of the code in the latest packaged release of eev from ELPA, as well as a bit at some of your email archives and video links. What I see is that you like things extraordinarily concrete and packages like Hyperbole and Org try to build up generalized abstractions that can be used in many contexts. When you try to break down how these abstractions work at the very low-level concrete mental model you like, you find them too complex and therefore have to set them aside. If you can't bend on that, then I think your choice is right, to just build large amounts of low-level code that meets your needs. I think the way you archive long lists of hyperlinks into videos for every few words spoken in the video speaks to this style. I see the utility but this is not a common style or need. It feels like we are offering a 'pour a glass of water' function and you are trying to understand the physics of the molecular movement within the water while it is pouring. Because you struggle to do so, you decide you can't use our functions/capabilities, which is fine if this is how your mind works, but really should not be a commentary upon the packages provided.
You see each day new people are coming to these packages and figuring out not only how to use them but to extend them to meet their needs, either through new hyperbutton types or snippets of additional code. So they can be bent to people's wills but you have to be willing to deal with abstractions, not the equivalent of assembly language to do so.
Maybe if you could pick a single eev function that you think could be implemented with Org and Hyperbole and pointed us to the documentation for that, then we could show you an equivalent one using these packages and begin to give you a better sense of how you would go about leveraging what has been built. You document everything in detail, so this should be pretty simple.
From my perspective, I do really like your idea of replayable notebooks for training and interaction purposes. And you have certainly made that easy to use via eev. But your implementation could use much better organization and abstraction which would likely greatly reduce the code size as well. You should separate out computation of what you want to display from how and where you will display it as one technique.
-- rsw