I had a glance at the other articles when they appeared and re-read them before answering. First of all it is a bit of a misnomer: Your goal is not to actually teach: you want to present exercises and evaluate responses. Teaching needs a storyline, a concept of independent modules doesn't help with that.

Your second article contains 460 lines of code but not a single line of POD - sorry, I didn't spend time to walk through that. It doesn't give the impression of No one line of code has stil been wrote.

I almost suspected that you aren't aware of the technical decisions you already made. I don't mind PPI - that's what I'd call an "internal affair". But there are others:

• You define courses and lessons as Perl modules. This is weird. Both courses and lessons are mostly data, in particular text, and not code. I don't believe that Perl modules are the best format to write lessons and exercises.
• You have each course to be a separate class, inheriting from your base class. Why? Why not different objects of a class you're providing?
  

  For this particular decision, I might be able to hallucinate the problem which you actually want to solve: You want authors of courses and lessons to be able to distribute their work. I don't know whether that is what brought you to the idea to use modules and CPAN, but CPAN would allow to "install" different courses by their name, therefore offering some method for distribution. As far as I'm concerned, I'm out: I don't have a CPAN account.

• You claim that you don't need to separate logic from presentation because you have mainly Perl data. Well, that's a direct consequence of the previous decision, isn't it? You surely know that web applications usually mix static data (templates) with database data, XML documents, and other dynamic data. The value comes with these dynamic data, not unlike to your situation.
• You dislike the idea to have external, yaml or json, files containing the data to be served. That's a decision against technical solutions, but with a rather lame reasoning. It isn't you who writes the courses, right? Do you have enough authors who share your preferences?

So, how did I guess that you use scripts to store objects? You wrote: I have designed it to have incarnations (game scenarios in this case) as standalone scripts and this approach lead me to shell out when changing the current scenario. If you can't get a scenario's attributes without running a script, then I guessed the script stores this scenario's data. This may be wrong, or at least irrelevant.

And finally, about OO frameworks: I didn't mention roles, and I didn't even have them in mind. All problems can be solved just fine without roles, but roles can bring elegance by avoiding boilerplate code. But Perl's OO frameworks have a lot more to offer. The issue is that there are too many of them :)