It's hard giving advice without knowing full context. I coached a team with a similar situation to yours, except the products were mobile apps instead of plugins. That team had a really hard time having ~8 product backlogs, so they consolidated it into one "team backlog." Because they wanted to keep the team working together as a team, have a consistent focus for a while, and keep product skills cross-pollinated, they focused on release themes, and tagged their product backlog items according to the release theme the PBI belonged to.
So, as an example... Products(in your case, plugins) A, B, and C.
Sprint 4 might include PBI's tagged with "A v3.1" (Release 3.1 of product A), "B v5.2", etc
Sprint 5 might include PBI's tagged with "B v5.2" (finishing up the release), "A v3.2"(small), and "C v1.7"
The releases were done completely separate from the sprint end boundary(and occurred 1-2 times a sprint), though all code was "potentially shippable" pretty much all of the time. Scrum says that the end of sprint increment must be potentially releasable, but Scrum does not prohibit you from releasing any number of other releases at any time. This is something a lot of teams don't understand. At the minimum, the end of sprint increment must be potentially releasable. How many other releases you want to do is up to you.
The focus on one(or at max two) product at a time allowed for teamwork, swarming, cross pollination, and focus. The releases were small incremental releases so that no one product would "hog" the team's bandwidth for very long(or if it did, for good reason!), and this allowed the releases to essentially be ordered by value on the product backlog. It also allowed value to be assessed across products.
As you can imagine, the downsides of creating small separate teams/backlogs can be that the most valuable stuff is in product A, but there are only 1-2 A developers. Meanwhile B and C developers are working on things not nearly as valuable, because they are restricted to working on their own products. Also, this tends to silo the tribal knowledge about the products and doesn't allow for as much parallel development and bottleneck removal. Having said that, there may be a good reason to go with separate teams, so there are not clear cut answers here. There may be more to your context than we know.
Like Dominik said above -- start with something quickly and try to iterate towards a better way.