OK, so that is one example of the kind of thing you want to communicate. An iteger.
And, you have finally said what we need to be able to do with this data. We need to control branches in the lesson.
Doesn't that kind-of imply that the only data-type we need here are enumerations. That is, the lesson lets the teacher create navigation structures that would be a switch statement in code?
Now, it is absolutely vital to think about user-interface design. To know what properties each element of this enumerated type must have, in order for us to build the lesson, we need to think about what UI will be presented to the teacher when they try to use this property (rather than another) to build the lesson; and we need to think about what the student will see as they attempt the lesson.
For the teacher, we presumably need some sort of name, by which they will identify what this property is, so they can choose it. Moodle will also need some sort of unique identifier to use to refer to this property.
Then, similarly, each possible value will need an internal, and an external, representation. But, going back to the external representation. What about internationalisation? Are these strings typically user-input, in which case they need to be processed by the multilang filter; or are they lang strings, in which case where in the process do they get looked up in the current langauge?
I don't know how much information students are given about why the lesson is taking the path it is taking. Perhaps they don't need to know about these properties at all.
Now, do you see why I think UI considerations are important when we talk about lower-level API design? Although the code should evenutally end up nicely layered, we need to see the big picture, and make sure that each layer servers the needs of the other layers, as we work out the detail of each layer.
To give an example from a completely different part of the API. Think about the $qa->get_state() method. You could argue that to give question behaviours and types as much flexibility as possible, we should let this method return anything at all. However, if we did that, it would be completely useless. The point of the get_state method is to allow other parts of the system to have some idea what is going on inside an attempt at a question. That is why the get_state method is only allowed to return one of the pre-defined qustion_states defined in this diagram: http://docs.moodle.org/dev/Overview_of_the_Moodle_question_engine#More_on_question_states (which as it happens is no up-to-date. For a difinitive list see question/ending/states.php). By restricting the flexibility, it makes it much easier for other parts of Moodle like the quiz or lesson to understand the answer it gets from the API. Of course, it took a lot of careful thougth to get the right state-diagram. (That is why it changed after the diagram was drawn.) However, the final state diagram contains all the flexibility that all the question behaviours so far concieved require.
Remember the quote "Perfection comes, not when there is no more to add, but when there is no more to remove." I am asking you to perfect your proposal by removing as much as possible.