Nu är det ju inte riktigt så enkelt som du beskriver, att bedriva utveckligen av Windows är ganska komplext, mer komplext en vad du troligen kan föreställa dig, till att börja med så finns det i stort sätt ingen "färdig" version ab Windows i den bemärkelse som kanske många tror, jaha nu är Windows 7 "färdigt" va skönt då kan vi börja om på nytt, planera för och utveckla "Windows 8". Så fungerar det inte utan man jobba med ungefär ett 10årigt perspektiv av development cyckeln när det gäller Windows, Med det innebär det också att det pågår en hel del parallel utveckling, de flesta skulle nog skratta åt mig om jag säger att man har kompilerat "Windows 8" builds i månander? Att hantera vad som ska in i vilken version hanterar om prioriteringar som görs utifån ett antal olika faktorer, så sent i release cyckeln som Windows 7 befinner sig i just nu, och har gjort ända sen RC Escrow dvs I mars någon gång så vill man inte utföra större färändringar i koden, helst inga förändringar alls om det INTE rör sig om så kallade "showstoppers", en "showstopper" är en blocking issue som gör att ett visst kund segmement, eller större enterprise företag inte kan rulla ut Windows 7 p.g denna, då kommer man prioritera en sådan DCR/Bugg och se till att fixa den.
Så till din fråga/kommentar egentligen? Varför shippar man Windows 7 (eller någon version av Windows över huvetaget) med buggar? När man vet att dom existerar, och kanske till och med har en lösning på dem?. Anledningen till att man låser ner koden som jag förklarat ovan är att om man skulle försöka fixa _alla_ issues, så kommer dom tillsammans faktiskt generera flera issues (kanske) tillsammans en vad dom från början va, vilket fall som helst så är det oftast en o kontrollerad tidsfaktor. Låt mig ge dig ett exempel från utveckligen av Longhorn/Windows Vista: Gruppen Power Users implementation i tidigare OS, (Den infördes i Windows 2000) visade sig inte vara helt lyckad, man kunde genom att vara medlem av denna potentiellt sätt bli administrator.. Så man beslöt att tabort gruppen, 4st builds jag testade hade man tagit bort gruppen som åtgärd. Detta fick förödande konsekvenser i form av intern kod som va beronde av gruppens existens (viss detta hade man kanske tids nog kunnat korrikera) men för och inte tala om de flera tusen 3parts applikationer, tjänster och integrationer som slutade fungerade bara på grund av gruppens existens, gruppen finns nu alltså kvar men ger inga speciella rättigheter, Det är alltså inte bara o "fixa till" nått och sen tuta o köra, ibland kan man även veta med sig att man behöver förändra så pass många komponenter att man senarelägger en feature/fix/dcr/bugg till nästa version av OS:et.
Så det är inte speciellt konstigt att man börjar hantera "fixar" i en separat branch som sedan kommer att resultera i ett Service Pack, Se det som en fortsätt "normal" vidare utveckling av Windows.