I'm curious as to why you're splitting into three teams rather than 2.
On the surface, I see two types of work: ongoing product work and integrations.
The ongoing product development includes proofs-of-concept for complex features, "regular tasks", and production support. If you have a sufficiently high-quality product, the vast majority of this work can be handled in a regular cadence. If you have frequent high priority interrupts, you may need to look at resolving those before you can fit into a regular planning cadence.
Third-party integrations are a different beast. They are often far more well-defined and have less uncertainty, ambiguity, and variability than product development. A different funding model and a different development life cycle are best suited to this type of work.
Depending on the architecture of your system and the level of demand for each type of work, it may be possible to shift some work between these two teams. Specifically, I'd want to understand more about the projected work related to third-party integrations and production support.
If you really wanted to be more accommodating, I'd potentially even look at moving away from Scrum. Some of the concepts may be useful, but there are likely ways to form stable teams around particular bodies of work that are changing. Again, following a two-team model, one team could be working on proof-of-concept work and production support for a month or two while the other team is doing product development, perhaps based on POC work that they did the last cycle.
I think there are plenty of options, but settling on 3 teams and the way you've organized the proposal is too constraining. With a bit more of an open mind, I think there are some good options that keep people engaged. This may be a good opportunity to let the individuals self-organize around the two leads and develop a way of working that supports the business as well as their individual needs.
