No, it doesn’t. It butchers the separators in the URL params and makes them HTML-escaped (& instead of &), so the URL doesn’t make sense anymore.
Please closely examine the examples of correct (0.139.3) and incorrect (0.139.4) behaviour I’ve provided.
Because for the iframe tag (that youtube shortcode produces), the src attribute is supposed to contain a URL.
And while the query part of URI is not well defined in standarts, it is universally recognized that the query delimiter should be an ampersand (&). You are correct in that this is not set in stone, but I’m unaware of any implementations that would treat the five symbols & combined as a query delimiter.
Yes, I did. The query delimiters end up being & with that shortcode, too; no change from a simple {{< youtube 0RKpf3rK57I >}} (other than the additional parameters being set to non-default values).
Perhaps. I don’t see how it changes the fact that 0.139.4 produces incorrect HTML where 0.139.3 produced correct HTML.
I think what’s going on here is a preference, not a broken function or a bug.
All browsers treat & in iframesrc as a delimiter. There is also no official ruling on & in that attribute, mostly because it leaves the interpretation of the query to the receiving entity:
The query part of a URI in your link actually has a little table next to it that talks about & and ; as delimiters.
Its syntax is not well defined, but by convention is most often a sequence of attribute–value pairs separated by a delimiter.
It’s the task of the receiving “processor” of that information in the URL to sanitize it.
As far as I could test on the iframes I have in my projects, any map/video/embed provider interprets & as & or as a delimiter. I remember times in my early days as a developer (last century) when some browsers had issues with URL-encoded attributes. Those were treated as browser bugs back then.