in some ways it's good that you're slow at the end of a sprint, that means your estimating well and not over committing, as far as keeping busy, on scrum teams I have worked on we always added research tasks for what's coming up next sprint.
This could be doing proof of concepts for things that are coming up, or looking at where to re-factor existing code, working on getting better test coverage on your code, etc.
I have previously been the Scrum Master for a team that was developing two products. The covered the same market space so it was understandable we would work on both of them.
We created roadmaps and developed stories independently and then combined them into a single backlog. That way we always knew which product took priority and could select items to work on appropriately. It was much more work for the Scrum Master and Product Owner, but made it easier on the rest of the team since they just viewed each story as a bit of work and didn't give much thought as to which product was more important.
The biggest challenge for the Product Owner was nailing down the priority between stories. One product had a larger installed customer base, but was in sunset because of technical limitations and the other had a long list of "must have" features. It was a balancing act to keep getting out new releases of the old to hang on to existing customer while providing new features in the new to attract new customers and (more importantly) get existing customers to migrate. In the end he had worked it out so the backlog was a pattern of 4 product A stories followed by 1 product B story. We had played with it a lot to that point and I know that since I've left they are still making adjustments based on the business needs.
His other big challenge was determining what frequency he wanted to release updates. Although both products were kept shippable at the end of iterations, it became as much a strategic decision of how releases would appear to the customer. In the end he settled on quarterly releases of the new and old, with the old coming out a week or two later. I can't say if that was the best decision or not.
In my role as Scrum Master, running interference for the team from outside forces was more complicated as people outside the team were frequently a positive influence on one product, but a negative on the other. For example, people we needed to consult with regarding the technology in the old product would sometimes try and make demands on changes to the new product in the middle of an iteration. So I needed them to sit with the developers, but keep focused on why we had them there.
There was also a lot of work in getting the team to see value in working on either project. While there is always better and worse assignments within a project, getting someone to pick up a dull task in a dying project for an iteration means you really need to sell the value of the work. Sometimes you had to highlight the dollars involved in the change.
Another issue the popped up every few months was a suggestion from upper management that we split the team into "vision" and "maintenance" teams. This was a group where people had been members for 3-10 years and they were suggesting splitting it just to make the resource allocation look better on paper. In reality, it would have hurt to take anyone off the maintenance permanently and by the same token not making someone part of the vision would have left them jaded or worse. I was constantly selling the value of the team as a whole was greater than the sum of its parts.
Estimating stories was difficult whenever we were picking up an area that hadn't been touched in a long time. It became difficult for the team to remember easily what other work had been done there and how they had sized it previously. This just meant that before estimation meetings I had to spend a few hours digging around through our old iterations to find similar stories so I could remind them of what else we had done in that area. How it had been sized and how the story had worked out in reality.
Another mechanical issue with the Scrum was running daily stand-ups in a way that kept it clear which product we were talking about. We adopted the approach of talking down through the stories rather than around the room to keep it clear. This was especially important when both products were updating the same technology in the same iteration.
Best Answer
Teams practicing agile are supposed to be open to experimenting don't they? You know, "people over processes" and such.
Try splitting to two teams per their languages and see how it works. If it turns out problematic, you can try one-team approach.
update, based on clarification provided in comments
You got my idea 100% correctly, and I think you're approaching the issue the right way.
As they wrote in The Pragmatic Programmer more than ten years ago,
One may say that Agile reinforces this olden-but-golden philosophy by making continuous adjustments an explicitly welcome part of development process.