Conflict between priorities and skillsets in the backlog
So we have a very diligent PO who does a good job of prioritising the User Stories in the backlog when it comes to planning. Much of the work is highly specialised though, and - as well as being Scrum Master - I'm a generalist developer and my team has some quite greenhorn juniors. Hence, what happens at planning is that our sprint gets filled to capacity, but then there are people (often me!) left with low allocation because there aren't really that many stories appropriate to their skillsets and levels.
My instinct (especially in this time of remote working when communications are harder and motivation is not always guaranteed) is when the sprint is full, to skip stories in the backlog to find them things they can do. This has annoyed the PO as he wants things done in priority order.
So there's conflict here - stories ordered solely by business goals might not get done, or might get poorly done if allocated to the wrong person. Even skilled devs working in a relatively new area will make mistakes. And switching people in and out of epics seems like a bad idea in some ways. My pragmatic solution - keep priority order till the sprint is full, then skip, hasn't been accepted by the PO and I am left a bit confused as to how to move forward.
The Scrum Guide does not talk about prioritizing the Product Backlog. Instead, it talks about ordering the Product Backlog. Priority is only one factor that can be used to determine the ordering of the Product Backlog. Dependencies between work items is another factor, but the Product Owner can choose any factors that are appropriate to help maximize the delivery of value.
The Scrum Guide also talks about cross-functional Development Teams that take accountability for the delivery of a product or service without recognizing titles or sub-teams. Although it seems like the team, as a whole is cross-functional, it seems like there may be sub-teams (perhaps of size 1) within the team. It's natural for individuals to have specialized skills or preferences as to what work to do, the emphasis needs to be on maximizing value delivery.
This is where the Development Team and Product Owner need to come to some level of understanding and agreement on how to proceed. One option is to do what the Development Team is doing now - everyone focuses on their particular strength if they have the capacity, even if the work they take is not the next most important. The other option is to work on developing the skills of the Development Team members so that everyone is more capable of taking on any piece of work.
There is a risk of having someone with less experience in a particular domain working in that domain. However, that risk can be mitigated through various teaching and mentoring options. Eventually, though, the skills of everyone on the team can be leveled up.
Fundamentally, that is the choice. Either Development Team visible output can take a short-term decrease as the team builds their skills in other areas or the output can be maximized yet this may not maximize value.
Personally, I would tend to favor the short-term decrease and build the skills of the whole team. This reduces dependency on individuals and the overall risk of the product. Not only would it achieve the results that the Product Owner wants to see, but it would also make sure that there are no single points of failure in the team with respect to skills and knowledge.