This is indeed new, caused by I0e136f952302b65f1abeeac5273bd842867e1dac. I don't consider this a big deal though, since something that contains a reference should never be used as an element's id anyway.

In T99787#1302535, @Jackmcbarn wrote:

caused by I0e136f952302b65f1abeeac5273bd842867e1dac.

That's rECIT944b24542827f827cdfb8646f1c2e87aeb929b65

What I showed above is a simplified test case, the template code is id="{{anchorencode:{{{1}}}}}" so it didn't break whatsoever was passed as {{{1}}}, we have around around 50k use of that template on fr.wikisource.org and ref in title are not so rare like here : https://fr.wikisource.org/wiki/Page:Helv%C3%A9tius_-_%C5%92uvres_compl%C3%A8tes_d%E2%80%99Helv%C3%A9tius,_tome_6.djvu/3

Where is the documentation in mediawiki-core explaining that == foo<ref>bar</ref> == is disallowed as the above patch seems to break it too ? see https://fr.wikisource.org/wiki/Utilisateur:Phe/Test17

Okay, this is trickier than I thought. The problem is that the easy way of fixing this will result in this breaking:

Template:Foo:
Something{{{1}}}. Something else{{{1}}}.

Some page:
{{foo|<ref>The reference</ref>}}

Specifically, a naïve fix will result in both of those elements having the same ID, and only one backlink being generated.

Change 213313 had a related patch set uploaded (by Jackmcbarn):
Don't run references if the output type isn't HTML

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

Change 213313 merged by jenkins-bot:
Don't run references if the output type isn't HTML

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

This seems to cause wrong rendering of TOCs when using <ref> in section headings. See T101390: <ref> in section headings shown as raw text in TOC.

Also seems to be affecting refs that are added into the alt attribute of inline images.