The hard part isn't implementing the change - although having to implement it in n different places doesn't help - the hard part is having to coordinate the change with n different teams to get the change out.
I feel this is the reason why microservices end up being attacked by clueless developers, because ultimately they are the scapegoat for organizational issues.
The primary selling point of microservices is that they are a management tool, as an org can use them to build teams with a very specific and clear-cut set of responsibilities. Microservices end up being a realization of Conway's law. Consequently, microservices end up being leveraged in intra-organizational conflicts.
It's not that microservices cause these issues, but that the organizations that run microservices cause these issues. If you have the same team managing multiple microservices, these problems don't happen because they don't have the coordination problems that separate teams endure, specially when managers clash.
It's the reason covered in the video you're commenting on, though. Except that "teams who happen to own microservices experience org coordination issues" is spun as "microservices owned by teams cause organizational issues".
From their inception, microservices were always a management tool, which happens to have operational and technical benefits and tradeoffs. If a project goes through challenges because they can't get all teams on the same page, that is not a technical problem.
Why not decide if it's generally seasons or episodes that need to be sorted above and introduce a simple tag to accomplish.
IE: Black Mirror S4 is given a promo/priority flag and any season marked promo is sorted to the top.