Question of the day: Is this class designed to do something in the future? The current implemantation would be more of an interface instead of an abstract class...

A few thoughts:

• if it were an interface, it'd force implementation of all methods - pre_dispatch() - for all controllers. Otherwise they remain abstract and PHP will bail. Some of them have pre_dispatch(), but it doesn't seem a must for all, atm?
• same goes for eventually settings() in admin controllers. Many have it, but not all.
  With an interface all are forced to write something (be it something empty), with a base abstract class, we can add an empty implementation in the base class, and who cares and needs to override it, will; the rest will just inherit it with no change needed.
• sometimes, during Ema's template_layers experiments, I've seen the possibility that an object of the template layers class could be an instance var in any controller, initialized when execution of action_something() starts, and used to add layers to. It'd have a place as protected in the base class. To note, this isn't an intention, it's a just a thought, but having a base class already will save us from making it then.
• sometimes, during earlier (well, middle-late, lol) work on Action class, I've been playing with an isAllowed in the base controller class, or a dispatch(). I'm not happy with the results, and I'd rather keep things plain and explicit, i.e. make in action_index manually what we need to make on subActions, using Action class. But in case a need appears more clearly than before, perhaps we can reconsider using the base class for some default implementation of controller dispatch.
• for Elk, templates and languages are simply procedural files. Even the 'engine' loading them, is our core functions in Load.php. With Ema's template layers, and perhaps with language files loading (Arantor had interesting comments on potential improvements), we might want a template engine object, and a language engine object, which - as above - a base controller could always initialize and be done with; all will just add/call stuff on them.

That said, I don't feel there is any issue at all to add an interface. Or, an extra-interface 😸 I'm just tempted to keep the object oriented model to its simplest; simplest which does the job with no burden.
An abstract base class is an interface conceptually, after all; but, it also allows defaults.
We could give up pre_dispatch(), or implement it in all controllers; or we can add an extra-interface (Action_Controller implements Controller). I'm just curious the other way around, why it'd be a "actual" interface?

Sorry for the late response...

I can see the benefits of an abstract parent class now .. the current scaffolding design reminds me of an interface (primarily because the functions are emtpy ) but a parent class (abstract or not) has definitely some benefits, at least it allows to easily extend all childs functionality at once ..