I can see a bit different approach in your workflow, which I like. In our lists, we don't track specific releases, the cards are just continuously moving up the chain. In your approach you are tracking releases separately from the backlog.
I think the last part you mention, to keep a card limit, is what broke our system from time to time. And the reviewing is probably very important, so stale cards are not kept around for no reason.
Is there a special way you organize your backlog board? Such as sorting it in themes of your application, urgency, etc? And do you keep track, if it was an external user request (and from how many) vs internal request (your own ideas) or other metrics? Do you find attaching estimates help, such as effort + impact?
One list for each priority/case-type pair, so High-bug, Medium-bug, ... High-Feature, Medium-Feature, etc'
> ... external user request
If support made the card, they attach the case. No reporting on this though, it's mostly for followup -- when the card is moved to a Done, we can let the customer know what release it will be in.
> estimates
We do a very high-level estimate bucket. Mostly to size the release.
> high-level estimate bucket
How does this bucket look like? Something like: `within 6 months`, `3 months`, `this month` or kind of effort oriented like `high effort` (takes long), `medium effort`, `low effort` (quickly implemented)?
So, left to right on the main board: Inbox, v.nextNext, v.next, In process, Review Requested, In Testing, Done.next, Done.nextNext
Done lists get moved to a "Releases" board when the version is released.
Inbox is triaged once per week to somewhere on the Backlog board or to a current release only if it's urgent or a regression introduced by those releases (like the bug was found in a beta)
The key to using Kanban, IMO, is to keep the number of cards pretty low. Use a pull to bring cards on when lists get empty -- do not just keep adding.