In the qusestion bank 4.0 project, a lot of very old code was moved into new plugins, and improved a lot. And, the new API for those plugins interacting with te core question system is pretty nice.

However, the API for other bits of code wanting to inteact with the question bank was not sorted out. We need a proper API there.

For example, when certain core functionality moved into a plugin (e.g. qbank_preview) we ended up with core code having to call a helper in that plugin, to get the preview URL for a question. This violates Moodle's principles on https://docs.moodle.org/dev/Communication_Between_Components. qbank_customfields is another problem (see MDL-72752).

Some additional development information:
I remember we talked about doing it action based, eg question_bank::get_question_action($questionid, 'edit'); or question_bank::get_question_action(int $questionid, string $shortname): question_action, if an action can be used as an standard action, its an standard one, or else it can be a new one. I can think of creating a specialized class to handle this, kinda like question_edit_contexts.php

keep the main public API on the question_bank class, but as you say, putting the implementation details in a particular class seems like a good idea, so it becomes something like

class question_bank {

public function get_question_action(int $questionid, string $shortname): question_action

{ \core_question\local\question_action_manager::instance()->get_question_action(int $questionid, string $shortname); }

}