Yes, obviously, [ \t] will also pick up a space character. So duplicate column 0 entries still work nearly-correctly? What would happen?
I'm not sure what you're asking. If there is more than one symbol for the same value, it should work correctly (the APPEND won't happen if there are any lines beginning with "VALUE "). If you want to append your own symbol where one already exists, you wouldn't use UNLESS with the (Column 0) value, and it would work fine (but WeiDU will choose the last defined symbol -- the one you just appended -- when decompiling scripts and when compiling dialogues). (Near Infinity works opposite here, and the first defined symbol wins, so it shouldn't change NI's decompile behavior at all).
Nythrun just said "Stats.ids in BG1/BG2/Tutu contains tab delimitation". So I suppose they shouldn't use tabs, but you'd still have to use a different regexp to catch Stats.ids entries, like [^A-Za-z0-9_], right?
It's common to use a bit of code to create a 4-byte value with the characters you want to test for. Nythrun has a cleaner bit of code, but it usually resembles
INNER_PATCH 1234 BEGIN
WRITE_BYTE 0x0 0x20 // Space
WRITE_BYTE 0x1 0x9 // Tab
WRITE_BYTE 0x2 0xd // CR
WRITE_BYTE 0x3 0xa // LF
READ_ASCII 0x0 whitespace (4)
END
When constructing your expression, you'd use [%whitespace%] to match any spaces, tabs, or line breaks in the source string. (But be aware that I've had only limited success getting this to actually work correctly with WeiDU on Mac OS X.) It's almost never necessary when specifying constraints for APPEND, etc., however (but it would be useful in the case where a string you wanted to match already had tabs or line breaks).