Various folks at WRI have spent a decent amount of time running this to ground, and I now think it's well understood thanks to a considerable team effort. Here's what we know.
Problem #1 — Screen littering
This aspect of the problem is specific to Windows1. The timer mechanism that we use under Windows (WM_TIMER) turns out to be surprisingly low priority. Such an incredibly low priority that even low priority paint events (WM_PAINT) trump them. Windows will simply not issue a timer message if you starve the system by pumping higher priority messages (and everything is higher priority) at it.
So, anything which retriggers itself, requiring constant computation, will do it. For example, this will do it:
x=0;Dynamic[x++]
Then start typing, and you'll see the screen litter. This seems like it should have been easy to catch in retrospect, but hindsight is 20/20, and for whatever reason, we didn't see this.
The timer thing has always been true under Windows, but in v10, we started pushing more things through the standard event handling system and through timers (as opposed to running them through tight loops which ignore system events or handle them circuitously) in an effort to make the entire system more responsive. This effort led to the regression, which we never properly characterized until recently.
Problem #2 — Rendering some graphics leads to high CPU usage
This turns out to be a problem on all platforms. Some graphics (it's difficult to properly characterize which ones, but typically complex ones with significant usages of Inset) lead to high CPU usage when onscreen. This high CPU usage doesn't come from Dynamic evaluation as one might expect...just displaying the graphic leads the FE to erroneously invalidate its cache of information used to format the graphic onscreen (and by format, I mean things like determining the width and height of things, the proper fonts and options to use, etc.). So, the FE keeps running this computation over and over again.
On every platform, displaying such a graphic will dominate one core of your CPU. On Windows, the act of doing so will then trigger problem #1, making what was originally a minor problem much more noticeable. Also, I suspect that recent versions include visualization functions which are more likely to expose the problem than earlier versions did.
This problem has been around for a frightfully long period of time, and it's entirely possible that it has been reported in the past. But, as a result of problem #1, the symptoms are much more serious, which raised the priority of looking at it.
Fixes
We're working on fixes to both problems. I do not expect either of these problems to be fixed in the forthcoming 11.0.1, as the fixes to these problems carry sufficient risk that it would necessitate a significant delay in the 11.0.1 release. But it should be ready in the next release (sorry, I can't comment on the release date for that yet).
And, incidentally, we turned our attention to this bug when we received numerous reports from users about it (6 distinct users reported it to our Support team as of this writing). That's what gets our attention. As I've said many times before, if you want to influence WRI's priorities, the way to do so is to find other folks who have similar concerns and make yourself heard through the Support team. It's a good system which helps us to understand how to prioritize limited resources.
Workarounds
If you have a self-triggering Dynamic, that might be an indication of a bug in your code which you should fix. Otherwise, or if you're running into a graphic coming from a visualization function which seems to be causing the problem, then temporarily hiding the offending cell will clear the litter. You can do this by scrolling the cell off the screen, or by hiding it inside of a closed cell group.
1 Note that I'm not making a claim that there are absolutely no screen-littering bugs on Mac or X. But if there are, they have a different root cause than this problem.
