The idea behind limiting the WIP count in kanban is to provide everyone the opportunity to properly focus on the few items assigned to them and to progress those items to the next stage as efficiently as possible.
The problem with just piling all the work on that one developer is that the typical reactions are
- Try to work on "everything" at the same time, thereby losing efficiency in the context switches between issues
- Becoming overwhelmed by the amount of work and losing focus as a result of that.
Both have the end result that the developer becomes more of a bottleneck.
The biggest flaw in your implementation is that "unworkable" items get assigned to the developer, who then spends valuable time investigating the issue, only to come to the conclusion that he still doesn't understand it or can't do anything about it.
The biggest improvements can be made by ensuring that blocked issues don't get assigned to the developer.
- Issues that can't be solved within the current system constraints should either be closed as "Won't Fix", or should be put in a special 'Hold' status.
- Unclear issues/requirements should be assigned to the originator (or someone who can act on behalf of the originator) for clarification. It is the responsibility of everybody involved to avoid that these issues start bouncing back-and-forth.
- Issues that can't be reproduced should be assigned to a tester for reproduction and a description on how to reproduce. If it is really a one-off, it should be prioritized accordingly.
The system should allow some level of cherry-picking for the developer in the issues he wants to take up. After working on some very hard issues, it is nice to get rid of some low hanging fruit to get the backlog down a bit and give your brain a bit of rest at the same time.