We also use Scrum for teams that have both new feature and maintenance tasks in a given sprint.
On established, selling, products, it is uncommon to see a complete segregation between maintenance and new features. Engineers who developed feature X on the previous release are likely to support it in the current one, and can't be pulled 100% to new work. Engineers also become subject matter experts (SMEs) in a given area, and have to devote some of their time to maintenance while working on the next release.
As L.Young correctly points out, maintenance work also has release and sprint targets. So, Scrum has to work in situations where teams are organized based on technical ownership, and again, in my experience, it does.
Kanban is a good approach when it comes to troubleshooting and dealing with unplanned issues from the field. However, as soon as the issue is understood and slotted for a release, it should fold into the same Scrum framework that is used for new features.
In summary, there is no strong reason to reshuffle them across features: not unless there is existing evidence that the current arrangement does not work. Moreover, if engineers are already engaged on a mix of feature/maintenance work, and/or you have many small features in your releases, then such a change is likely to reduce productivity, and drag people into multiple concurrent feature Scrum teams.
On the other hand, if you have a few major features that occupy people 100%, and little maintenance work, then shifting into feature teams may help.
There's a bit more on that here: http://romankleiner.blogspot.com/2015/04/scrum-part-xi-module-teams-or-feature.html .