The equilibrium percentage of total capacity allocated to defect-fixing is equal to the defect injection rate.
Many factors can affect this rate, among them, of course: what kind of product the team is developing, what technologies and technical practices they use, the team's skill level, the company culture, etc.
Considering Team B, if they create on average 8 units of rework for every 10 units of work they complete, then working those 8 units will create new 6.4 units of rework. We can estimate the total effort they will eventually have to expend as the sum of a geometric progression:
10 + 8 + 6.4 + 5.12 + ...
The number of bugs will decrease exponentially with time, but Team B has such a coefficient in their exponent that it will go to zero very slowly. Actually, the sum of the first three terms in the above series is only 24.4; of the first five, 33.6; of the first 10, 45; of the entire series, 50. So, Team B summary: defect injection rate, 0.8; feature development, 10/50 = 20%; defect-fixing, 80%. 20/80 is their sustainable capacity allocation.
By contrast, Team A is in much better shape. Their progression looks like this:
40 + 10 + 2.5 + 0.625 + ...
The sum of this series is 53 1/3, so Team A's feature development allocation is 40/(53 1/3) = 75% and defect-fixing allocation is 25%, which matches their defect injection rate of 10/40 = 0.25.
Actually, all terms in Team A's series after the first three are negligibly small. What this means in practical terms is that Team A can probably squash all their bugs with a couple of maintenance releases, the second release being pretty small in scope. This also creates an illusion that any team can do that. But not Team B.
I thought about this equivalence while reading David Anderson's new book, "Kanban". (The book is on a different subject, but addresses quality concerns, too.) When discussing software quality, Anderson quotes this book, by Capers Jones, "Software Assessments, Benchmarks, and Best Practices":
"...in 2000... measured software quality for North American teams... ranged from 6 defects per function point down to less than 3 per 100 function points, a range of 200 to 1. The midpoint is approximately 1 defect per 0.6 to 1.0 function points. This implies that it is common for teams to spend more than 90 percent of their effort fixing defects." He cites an example provided by one of his colleagues of a company that spends 90% of the time fixing their bugs.
The fluency with which Anderson goes from the defect injection rate to the defext-fixing capacity allocation (failure demand is the term for it) suggests that the equivalence of the two things is well known to software quality researchers and has probably been known for some time.
The key words in the line of reasoning that I'm trying to present here are "equlibrium" and "sustainable". If we take away sustainability, then there's an obvious way to cheat these numbers: you do the initial coding, then move on to code somewhere else, and leave maintenance to others. Or you run up the technical debt and unload it on a new owner.
Obviously, no particular allocation will suit all teams. If we decreed that 20% must be spent on bugs, then, if a team has an ultra-low defect injection rate, they will simply not have enough bugs to fill the time, and if a team had a very high rate, their bugs will continue to accumulate.
The math I used here is way simplified. I neglected things like transaction costs (planning and estimation meetings, post-mortems, etc.), which would affect the percentages somewhat. I also omitted equations simulating sustaining one product and developing another one concurrently. But the conclusion still stands. Do what you can, in terms of technical practices, like unit-testing, continuous integration, code reviews, etc., to reduce your defect injection rate and, consequently, your failure demand. If you can create only one bug for every 10 features, you will have a lot of free time to develop new features and satisfy your customers.