Our teams work across multiple products and will often deliver functionality for these sporadically as required by priorities.
e.g. Work on Product A, then Product B, then Product C, then Product B again.
In a situation like this, would you number the sprints 1 to x ad infinitum, or for Prod A from 1 to x, then when starting Prod B re-set to 1 and repeat?
Sprints should not be named or sequenced in anything except a strictly ordinal sense, and that's really only for release planning or burn-down purposes. A Sprint is an ephemeral time-box, and a Sprint has no life of its own once the time-box has expired.
Ideally, you should have one team per Product Backlog. If you have multiple products, you should have multiple teams. If you choose not to do that, you still need the team to work from a singular Product Backlog, and each Sprint should have a cohesive Sprint Goal. If you need to communicate about the Sprint, describe it by its Sprint Goal; don't confuse the issue by trying to track Sprint A-12, Sprint C-16, Sprint B-9, and so forth. It buys you absolutely nothing from either a framework or communications point of view.
