Indeed. ViEmu 1.x used Visual Studio's internal system to group several actions into a single undo-queue action. The goal was that, if you use 'cwHello<esc>' or '2p', which perform several operations. VS's internal system has quite a few limitations, which prevented me from keeping an "open undo group" while in insert mode (syntax highlighting in several of VS's languages would stop working meanwhile, etc...). So ViEmu 1.x only grouped operations such as '2p' or '3x', etc...
Starting with ViEmu 2.0, I stopped using Visual Studio's internal system. I implemented a new system based on inserting dummy operations in VS's undo queue. If you open the undo queue while using ViEmu, you will see some actions listed as '---'. This operations are actually no-ops, that is, undoing and redoing them doesn't actually do anything, but they are looked for by ViEmu's implementation of undo and redo ('u' and '^r' commands). This system allows outstanding groups in insert mode (because they are not actual 'groups'), and thus ViEmu 2.0 is much more similar to vim in its undo grouping behavior.
The problem is that nathan ('sticks') pointed out above that the new system includes all VS-initiated actions (a VS search and replace, or VS's 'comment', 'uppercase', etc... operations) in the last open ViEmu group, thus, a 'u' may undo one ViEmu action PLUS several VS actions on a row.
I acknowledged the misbehavior, which I plan to fix in a future revision, but I also suggested a temporary workaround: use VS's Ctrl-Z to undo, which will undo single, atomic, non-grouped actions. The only problem with this workaround is that the dummy marker-action ('---') is also an action in VS's understanding, and thus there will be one extra Ctrl-Z needed which won't actually undo any real operation.
The proper fix, which I plan to implement in a later release, would be to sense 'external' (non-ViEmu) operations in the buffer, and insert extra markers, so that u/^R will treat these 'external' operations as separate from the nearest ViEmu operations.