If you're familiar with chess, you might know the old saying "a player with a bad plan will beat a player with no plan". As a general rule, once you commit to a strategy in chess, you should keep up that strategy unless diverting from it gets you a very clear gain which your opponent cannot overcome. A player who plays for the moment with no eye towards the overall game will rarely succeed in the long-run. Conversely, a player who only looks at the long-run will often overlook tactical opportunities and can be outplayed by a player who knows this weakness. The great majority of players, though, play for the moment. They might have an idea of some long-term goal, but they're constantly looking for short-term advantage. In chess, those players are generally known as "losers" because, well, that's what they do.
In programming, we see something similar. We take a bad system, we start refactoring, but in the interest of "getting it done now", we only get it halfway done. This is then repeated many, many times despite the intention of gradually migrating to the "better way". Then others come along and start to work on this system and they're seeing a hodgepodge of things like &some_func and &some_func_new. Some code uses the "old style" and some code uses the "new style" but it's not always clear when it's appropriate to use either.
To be fair, a company doesn't often have the resources to simply rewrite everything. Budgetary, temporal and resource constraints all conspire to keep a "half-baked" system half-baked. However, without disciplined management and programmers, this is a very tough problem to overcome.
Since this problem is one we see constantly -- knowledge that code needs improvement and many partial efforts of dealing with this -- I think it needs a name. Once something is labeled, it's easier to talk about and deal with. Does this common situation have a name? It would strike me as odd if it doesn't, but then, perhaps it's so terribly common that it's taken for granted rather than explicitly dealt with.