> How does the function check for a valid/supported encoding name in PHP? Is the
> request passed through to the library itself, or is there some kind of 
> whitelist implemented in PHP before the function call (that hasn't been
> updated for quiet some time)?

From a quick glance, it looks like the latter, see
<https://lxr.room11.org/xref/php-src%40master/ext/mbstring/php_mbregex.c#enc_name_map>.

In this case it seems, that the list, starting at line 186 "php_mb_regex_enc_name_map_t enc_name_map[] = { ...", prohibits the usage of GB18030 and CP1251, simply because these encodings are missing in the list.
The list contains all the encodings, which are currently accepted by mb_​regex_​encoding().

Interestingly, the list include some aliases, which are not returned by mb_encoding_aliases(). For example "BIG5" is missing and is accepted by mb_internal_encoding() and by mb_regex_encoding(). On the other hand, "ISO8859-1" is accepted by RegEnc but not IntEnc. For example for ASCII "ISO646" is accepted by RegEnc, but not by IntEnc, the latter only acccepts "ISO646-US", which in turn is not accepted by RegEnc. What a mess ... ;-)

I've made a simple test via modifying php_mbregex.c:

php_mb_regex_enc_name_map_t enc_name_map[] = {
#ifdef ONIG_ENCODING_GB18030
	{
		"GB18030\0GB-18030\0GB-18030-2000\0",
		ONIG_ENCODING_GB18030
	},
#endif
#ifdef ONIG_ENCODING_CP1251
	{
		"CP1251\0CP-1251\0WINDOWS-1251\0",
		ONIG_ENCODING_CP1251
	},
#endif
#ifdef ONIG_ENCODING_EUC_JP
	{
[ ... ]

and recompiled 7.2.0RC2. Of course, I got a unit test error in mb_regex_encoding_variation2.phpt, but mb_regex_encoding() now does accept these two encodings (and aliases) and a preliminary test with CP1251 worked with something like '\p{Alpha}{3,6}', but this might not be a trustworthy result, because CP1251 is a simple 8-bit charset.
For GB18030 I do not have the language skills to test it myself or even provide a useful RegEx.

(The macros ONIG_ENCODING_GB18030 and ONIG_ENCODING_CP1251 are already defined in oniguruma.h, line 233/235)