Point taken, but standard practice is to write correct code for a CSS bug, then write a 'hack' that works for that specific browser version.
On the other hand, if you're doing an intranet site with a company that only has one browser, you might have dispensed with writing correct code and only written the hack.
Its' temporarily practical in a time crunch, but not a good practice since the next update may kill your hack.
Note that there are also other cases where incompatible changes are made (e.g. ES5 is not exactly compatible with ES3 in various edge cases, CSS2.1 today is not quite compatible with CSS2.1 a year ago in edge cases, etc). The various standards groups an implementors try to minimize the damage from such changes, but it still happens at times.
Heck, Chrome 9 or 10, made major changes to the HTML parser to follow the HTML5 draft. Sites that depended on the old behavior (which different between browsers, so they presumably browser-sniffed and then sent different content to different browsers) likely broke. They certainly did in Firefox when Firefox changed to the HTML5 parsing algorithm.
On the other hand, if you're doing an intranet site with a company that only has one browser, you might have dispensed with writing correct code and only written the hack.
Its' temporarily practical in a time crunch, but not a good practice since the next update may kill your hack.