ACPI is an open standard, but unfortunately, vendors' closed source BIOS implementations for the last few years are written against the Microsoft ACPI parser, bugs and all. Consequently, many machines fail to work at all with the Linux implementation (written against the standard) unless kludges or more relaxed syntax checking are used. This is not a failing of the Linux ACPI implementation or the ACPI specification. It is a Windows interoperability issue.
It is unknown how many machines have bugs in their ACPI BIOS code. The only way the ACPI developers find these and special-case them is when users mail in their bug reports and DSDT (check here [sourceforge.net]), because the developers don't have access to every machine on earth to perform testing on. Even when a bug is found, it can only be worked around, because most system BIOS in the field are no longer supported by the respective vendors. So you'll see messages from the ACPI layer regarding syntax errors or known bugs in a particular BIOS, which the developers are helpless to fix in any way other than a special-casing.
Even worse is that many ACPI BIOSes return different values depending on which OS the vendor's ACPI code thinks you're running. Most of the time, any BIOS code path other than for an OS which calls itself "WindowsNT" is broken, so AFAIK, all ACPI layers simply spoof themselves as "WindowsNT" to the BIOS to avoid problems. Rather sad, isn't it?
As a final note, some vendors like Tyan, HP, Intel, etc are extremely active on the ACPI and LinuxBIOS mailing lists. HP has fixed ACPI-related bugs in their system BIOSes due to the Linux ACPI code rooting them out.
So the moral of the story is, don't assume poor ACPI operation on a specific machine is the fault of the Linux ACPI project. More often than not, it's the fault of the BIOS vendor not caring to implement the standard correctly beyond what it takes to get Windows up and running on the machine, which doesn't correspond 1:1 to whether or not they've implemented the standard correctly.