I wonder if it is possible to implement Bitcoin address prefix searching not only by the starting characters but also by any other positions within the address. For example, searching for characters at the end, in the middle, or even a combined search where part of the characters are at the beginning, part in the middle, and part at the end, and so on.
This sounds awesome

So, instead of quickly filtering the H160, you want to first encode it to base58, and then do some regex stuff on the b58 string. It'll definitely have no impact on the throughput whatsoever.
Puzzle 65→66: 35 bit flips
Puzzle 66→67: 31 bit flips
But bit flips between consecutive private keys are very interesting.

You're simply covering 99.999...9% of the range, if you do the math on summing up a few of these "how many flips on average". Of course, there are extremely low chances of having just a few flips, but then again, those account for 0% of the range.

I don't get why most people can't accept a simple fact: there is no cheating, all of these ideas to shorten the brute force are actually increasing the time. Only way to success is to check all pvtKeys to H160, as fast as possible, and there is exactly one single way to do it optimally: iterate, hash, check, repeat, on hardware that does it with the highest efficiency (hashrate / watt).