The correct Scrum answer is "Ask the team(s)". This is the principle of self-organisation where they should be able to restructure themselves to get the job done quickly. You see many people in the teams have more context knowledge than an outsider and they know what is best. This also includes the Product Owner.
I take it that you came here and asked the question as there is something that does not feel right and you have hidden concerns. So I am going to give you a few pointers to discuss with the team to come up with the right decision.
There is only one product owner for a backlog and this should be a business person or person representing business. It should not be IT management. A big backlog has many items and with multiple teams it could be too much for a single PO to deal with. You may want to keep backlogs separate for this reason.
If there are multiple PO's, then you definitely need multiple backlogs as teams should be dedicated in a sprint to a single PO and backlog. The reason is a team does not need to manage conflicts between product owners priorities.
Product Development versus Maintenance
Maintenance teams work on many small enhancements, bugs over several different products and possibly with several product owners. These BAU teams need the support of IT management to help schedule the and manage the conflicts between multiple product owners.
Project teams should focus on one product at a time to minimize context switching and delivering one great product at a time. Context switching could result in delivery of many mediocre products with some degree of technical debt.
Working on multiple products or different features causes context switching which slows down teams productivity. The PO should factor this in when working out what is next and what team should be working on what piece of work. The amount of switching is not insignificant and not just a theoretical issue, it is real and I have witnessed team dropping up to 80% in productivity due to this.
A good PO will try group features and type of work to help teams do less context switching, thus improving their performance.
Sadly, management try put the risk of time, money, budget and business pressures on the team; and teams accept this by agreeing to this. As a development professional, you should simply state the facts and impacts of the decisions and make the business own their own risk.
Agreeing to a ridiculous time. Rather say what effort its going to take to do the job properly and make business manage the time problem
Estimations. Business expect teams to accurately estimate in a world of complexity and uncertainty. Teams should ask business what they are doing to mitigate if the estimates are exceeded due to unforeseen challenges, which are highly likely. Teams should not factor in fat, but instead business should.
Technical Debt. Teams should estimate on doing high quality code that is fully tested and estimate on that, i.e. Stop writing defects due to pressures. If business want lower quality, then it is their risk to take and when things go wrong its their problem.
Be a professional by stating building the right things to the agreed quality. Estimate to your best ability based on facts at hand. When these facts change, communicate it and adjust the estimate. As a development team, build great products and do not take on business risk. Communicate and manage expectations.
Inspect and Adapt
Teams should always be seeking ways to improve and if they feel it is going to make things better, they should try it. Then inspect to see whether there are improvements. Finally they should adapt and improve on their new approach or scrap it if not working. The intent behind seeking to improve should always be there.
Ultimately, the management of the backlog is the choice of the PO. How he/she wants to manage the queue of work is up to them. The only think is they MUST keep the pipeline of work to ALL teams healthy and in a good state. It is thus up to the PO to decide.
In sprint planning sessions, the team should expect a list of groomed product backlog items that are clear, unambiguous and ordered. With a short discussion with the PO the team should know exactly what the PO wants; the WHAT. The team then focus on how they are going to build.
If the PO comes to the planning meeting well prepared, who cares how the backlog is managed. If the PO comes unprepared to the sprint planning meeting, this should be addressed by the SM and made very visible as this is totally unacceptable and not a team problem to take on.