It's correct that a product backlog shall be normally managed by one Product Owner and not by a committee - this ensures a proper vision and communication between the business side and the team.
But there are cases when one Product Owner is not enough, as when you have a large project (you mentioned it is a big system) and need to scale the process. Not enough means that one Product Owner is not able anymore to grasp an overview of the entire product (or of the backlog) nor to properly interact with the team(s).
A first scaling possibility would be to split the work among more teams (an agile team is small, no more than 8-9 members, because of the communication and coordination overhead). The product backlog remains still only one.
When the teams will be too many (possibly after 7-10 teams) the Product Owner will not be able anymore to work with all the teams or properly detail every item in the backlog. At this point you will need to introduce more changes.
A possible second step would be identify in the backlog major requirement areas and define the backlog with separate views, one for each area, and each one will have a dedicated Product Owner and dedicated teams. These area-backlogs are not separate backlogs but only a different view inside the one Product Backlog.
Note that these areas are organised around customer-centric requirements (really just a coherent fragment of the backlog) more than around product's architecture (like could be a split among different parts of the system) but could be temporary, can change over the lifetime of the product.
The area Product Owners (PO) may be in a Product Owners Team and actively collaborate to deliver the product (Product ROI, joint retrospective, …); for example, before any Iteration Planning the Product Owners Team should meet in a pre-planning meeting so that they can coordinate how the different Area-Backlogs priorities reflect themes at product-level, which PO will take care of common themes such as a common infrastructure, etc.
If this is your case - big system with different areas and teams - you can certainly have multiple Product Owners.
If you have only one team but the Product Owner changes every couple of iterations according to the part of the system being developed, well, this is unusual. You need to ask why this is beneficial: if one team can handle all the parts why cannot one PO?
The first Agile principle is inspect and adapt: try and see if there are any benefits or drawbacks.