In short: what happens is normal, you need to use API and custom code to solve it.
When you have more than a handful of videos, having so many video players in a page is a huge load, because they’re complex and eat a lot of memory and power. That’s always have been the case and even with today’s powerful computers, it’s still the case.
And there are induced other issues, such as having several videos playing at the same time because playing a new one doesn’t stop the previous one.
So for this case, and wether it’s YT or Vimeo videos, you have to use the respective APIs of the services. It means handling custom code.
When you’re using the APIs, there’s only one player engine loaded in the page, at all times, even if visually it changes nothing, you still under the impression that you have many players in the page. You also solve the other issues by defining the behavior of a player instance when another one is activated (e.g. player stops, pause, is replaced etc…)
Dealing with APIs is easy for a developer (so it’s quick, and inexpensive), not so easy for a Designer, however not impossible. (And Vimeo’s API is easier than YT API.).
There’s countless examples and helpers if you google them.