You want me to talk about myself and my ideas? Oh, the horror! :>

The simplest way is to not do velocity tracking any more, and to fall back on gut-instinct and general experience. If you have the instinct and experience, this can work, especially if you communicate very clearly with your customer about how things stand. It certainly isn't satisfying, though, and it's not as comfortable because there is nothing backing up your instinct that you can get a reality check from.

The next is to take all the bugs or weirdness that you know of, write stories for them, do your best to estimate these stories (these estimates are pretty much always wild guesses), and then continue. As you get more information, update the stories and the estimates. This is tough because the very nature of it works against you...once you know how to do the trick, it's easy. So, say you initially guess that "determine why the output file is corrupt" is 2 ideal days. You spend a calendar day investigating and determine that the fileheader is using the wrong kind of newlines; it takes you 10 seconds to fix the problem. Now that you've solved it, you know how long it took to solve and, clearly, your intial wild guess was too high. If you leave it as is, you are inflating your velocity but if you change it, what do you change it to?

This last scenario is the problem that made me post here on PM. So far, I don't have a good answer to it...the least disagreeable answer has been to change the estimate to whatever will leave my velocity unchanged.