As an update to this, it turns out that I can't read and talking about _OSI isn't very helpful when the DSDT in question is calling _OS, but it does leave me somewhat more confused - Linux has claimed to be Windows NT since approximately forever. Without the original DSDT I've got absolutely no clue what's going on, but comments like:

Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they're trying to crash the kernel by locking a region of memory that shouldn't be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead. ;)

don't give me a lot of confidence in any of this being a correct diagnosis given that the second argument to Acquire is a timeout and not an address (0x03e8 gives a timeout of a second, while 0xffff is "Block on acquiring this mutex forever").

In any case, it's highly unlikely that this is any attempt by Foxconn to prevent Linux from working. The majority of checks for Linux in ACPI tables are copy and pasted from reference tables that Intel (and other manufacturers) have provided at various points - even the Intel Macs attempt to check for Linux! Most vendors will never attempt to boot Linux on their boards or validate them appropriately, so it's entirely conceivable that they'll end up screwing things up in such a way that the only tested paths are the ones that are run by Windows. This is why we now attempt to ensure that Linux reports itself as Windows. If we're running Linux-specific code in the DSDT, then that's a bug in Linux.

Anyway. Accusing companies of conspiring against us when the most likely explanation is simply that they don't care is a fucking ridiculous thing to do and does nothing to get rid of the impression that Linux users are a bunch of whining childish hatemongers. Next time, try talking to someone who actually understands this stuff first?