Mark \Drupal\Core\Theme\Registry internal

Looks good, added some rationale to the IS.

This is RC eligible since it's just docs, but I'm not sure the rules around marking stuff @internal or not. And since this seems like a framework manager decision, assigning to alexpott, who I guess already talked to lauriii about this a bit.

+++ b/core/lib/Drupal/Core/Theme/Registry.php
@@ -18,6 +18,8 @@
+ * @internal
+ *

I think there should be an explanation.

+++ b/core/lib/Drupal/Core/Theme/Registry.php
@@ -18,6 +18,10 @@
+ *   new features in minor releases so this class should be considered final.

The last word is a little bit odd. I would have expected 'internal' ...

I think this is a good move to make this internal.

+++ b/core/lib/Drupal/Core/Theme/Registry.php
@@ -18,6 +18,10 @@
+ * @internal Expected to be used only internally since every hook_theme()
+ *   implementation depends on the way this class is built. This class may get
+ *   new features in minor releases so this class should be considered internal.

According to @jhodgdon @internal should stand for itself. Additional information can be provided afterwards

This is RTBC as long as the request in #11 meant "Stand by itself" instead of "stand for itself"

This needs a short change record since we're doing it within a stable release now - just gives people less excuses if they actually did subclass this to complain later.

Has the CR, rational seems reasonable to me, back to RTBC

Committed 7acb0de and pushed to 8.1.x. Thanks!

Is it not inconsistent to have a hook part of our public API ( hook_theme_registry_alter() ) access an @internal class ?

hook_theme_registry_alter is modifying a discovered array, not calling functions. No?

Indeed, but it contains a @see referencing this @internal structure.

The @see is a reference to documentation explaining the array structure passed to hook_theme_registry_alter. I do not see how this could be a problem.