Hi, some comments, surely none affecting this to go forward:
A) There are a bunch of (now) deprecated calls to get_plugin_types(), get_plugin_list(), normalize_component(), get_plugin_list_with_class()... a new issue should take rid of them in core. I think Sam commented about that above, but it became forgotten in your reply.
B) We need also another issue to consider the 3 get_plugin_list_with_[class|file|function]() functions. And provide alternative for the later 2 ones.
C) Tiny detail, or we use singulars or we use plurals. I don't like having "core_components" and "core_cache_definition" (for example), plz, homogenize. My +1 goes to singular (like we do in plugins and 99% of subsystems).
D) I'm not sure I agree about to move away from MUC and, instead, create a particular implementation of caching for plugins types, lists and subsystems. Of course it leads to quicker unit tests executions, but at the cost of breaking the principle of reseting for each test. Sure it's something that does not change between tests, but the same can be applied to a lot of other caches and we are reseting them a thousand of times. Seems unbalanced (un-pretty) for me.
E) Of course upgrade.txt requires MORE detailed information about what becomes deprecated, links to uses/docs... can be completed later, NP, but don't forget it.
F) Introduction of namespaces. While I don't oppose to this, I think this requires way more detailed documentation about the uses we are expecting and the do-s and don't-s with them. Note this is apart from this issue itself, but if we officially start supporting them, because of their nice autoloading capabilities, they need to be rulez in the docs/codings style/code checker. We should not allow, for sure, things like:
- bracketed nomenclature
- multiple namespaces (or classes) per file
- incorrect (non component) namespace prefixes. for example "\superduper".
- incorrect (non subsystem) namespace suffixes. for example "\mod_forum\inventedbyme" or "\core\becauseiwant".
Side note: Surely this is about to make the moodlecheck/codechecker checkers able to verify all these pieces of information together: @category, @package, namespace and path.
G) In the (future) process of converting current /lib stuff to new autoloaded classes... one of the most common cases is when we have at least 2 classes related with a given element. Say, for example (not sure if it's valid or no, just the idea): core_textib and textlib_exception, i.e. one class and one exception for it. How is that going to be done, using the \core\textlib namespace and then.... ? Or putting the 2 files into lib/classes and naming theand naming them textlib.php and textlibexception.php ...? It's a simple example, but I think we are plenty of multi-classes examples.
So I'd give this my +1, but please, clarify/don't forget about all the points listed above. This opens the gates to a great new way to do things, but it cannot be done without putting some fences in the field (aka, document, restrict, rule).
My 2 cents, ciao