@charitwo does the same thing happen with any other magic word?

To (hopefully) save others some time, I found that:
Line 187 of MagicWord from version 1.33.1 is part of

/**
 * Initialises this object with an ID
 *
 * @param string $id
 * @throws MWException
 */
public function load( $id ) {
	$this->mId = $id;
	$this->contLang->getMagic( $this );
	if ( !$this->mSynonyms ) {
		$this->mSynonyms = [ 'brionmademeputthishere' ];
		throw new MWException( "Error: invalid magic word '$id'" );
	}
}

(the brionmademeputthishere is likely from T22281: MediaWiki needs more easter eggs and can be ignored).
This function requires that mSynonyms be defined before the function is called. When a new MagicWord is created

/**
 * Create a new MagicWord object
 *
 * Use factory instead: MagicWordFactory::get
 *
 * @param string|null $id The internal name of the magic word
 * @param string[]|string $syn synonyms for the magic word
 * @param bool $cs If magic word is case sensitive
 * @param Language|null $contLang Content language
 */
public function __construct( $id = null, $syn = [], $cs = false, Language $contLang = null ) {
	$this->mId = $id;
	$this->mSynonyms = (array)$syn;
	$this->mCaseSensitive = $cs;
	$this->contLang = $contLang;
	if ( !$contLang ) {
		$this->contLang = MediaWikiServices::getInstance()->getContentLanguage();
	}
}

mSynonyms is defined using the second parameter to the construction. This specific instance of the MagicWord class is called from line 222 of MagicWordFactor from version 1.33.1, which specifies

/**
 * Factory: creates an object representing an ID
 *
 * @param string $id The internal name of the magic word
 *
 * @return MagicWord
 */
public function get( $id ) {
	if ( !isset( $this->mObjects[$id] ) ) {
		$mw = new MagicWord( null, [], false, $this->contLang );
		$mw->load( $id );
		$this->mObjects[$id] = $mw;
	}
	return $this->mObjects[$id];
}

and the MagicWord is created with a synonyms array of [], hence the exception. I don't a local installation to try and solve this, but maybe this will help

I actually had an error related to CategoryFunctions with regard to localisation when trying to run composer and update.php but disabled the extension then I ran rebuildLocalisationCache.php just to be thorough and then tried Composer Update then update.php and both ran successfully.

The one quoted in the task was after update.php ran and appears on any page, namespace including special.

In T235512#5580592, @WDoranWMF wrote:

@charitwo I'm going to downgrade this from UBN.

explain how a broken installation is a normal priority that makes no sense

@charitwo My apologies, I should have given more context. Our team is using UBN for production errors in our internal systems. We're trying to prioritise our backlog so we can order the tasks we can get to.

I didn't mean to suggest the severity of the issue for you was not significant. I'm going to be working with our Product Manager to figure out our scheduling and I'll get you an update from there.

Is there any update on this, @WDoranWMF ?

No - if there was an update, there would be activity on this task. :)
@charitwo: If you are interested in fixing this issue and would like to propose code changes, you are very welcome to use developer access to submit a Git branch directly into Gerrit which makes it easier to review and provide feedback. If you don't want to set up Git/Gerrit, you can also use the Gerrit Patch Uploader. Thanks.

@Aklapper I'm not a developer, I'm an end-user. Which is why I'm submitting a high priority breaking ticket for a core issue. The fact that it takes this long to patch is not okay, nor is your passive aggressive response in your first sentence.

@charitwo: Hmm, I don't see anything "passive aggressive" in my answer which is in a neutral tone. Regarding "not okay": Workforce is not unlimited and priorities might differ - see https://www.mediawiki.org/wiki/Bug_management/Development_prioritization for more context. Thanks!

I would say core code breaking a wiki is a large priority, especially if you skip throwing the exception...it actually works as intended

I encountered the same issue when upgrading a wiki to 1.34. Upgrading the LabeledSectionTransclusion extension to the corresponding 1.34 branch fixed it.

– (4aa6bfa) 02:55, September 16, 2019

4aa6bfa6274e6ac2675ec8e1811a5b1fac8a5ee0 first appeared in origin/wmf/1.34.0-wmf.23. If your wiki is still on 1.33.1, this may explain it; I'd recommend checking out a version of LST matching your wiki version (aka, check out the version from the REL1_33 branch). (In theory LST should be specifying a minimum required mediawiki version to catch issues like this, but it does not.)

I am actually on 1.34 now, I did not realize the original date of this task before you mentioned. I will try re-enabling the extension and seeing if the problem has resolved itself since 1.33.1

Change 592776 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/extensions/LabeledSectionTransclusion@master] Add minimum required MediaWiki version (1.35) to extension.json

https://gerrit.wikimedia.org/r/592776

Change 592776 merged by jenkins-bot:
[mediawiki/extensions/LabeledSectionTransclusion@master] Add minimum required MediaWiki version (1.35) to extension.json

https://gerrit.wikimedia.org/r/592776

In T235512#6087179, @charitwo wrote:

I will try re-enabling the extension and seeing if the problem has resolved itself since 1.33.1

@charitwo: Any news to share?