I take it MoFo was being naughty? I dont know how the updater works but could you not tell it to remove the file on update?

The reason for the change being?

And create a new file once the current one is deleted :). Also is there anyway I can assist you? I can't compile the code (Unless I use it on linux) but I am able to edit.

I have this problem with 64 bit version of powder on Linux. It crashes when powder runs with scale:2. 32 bit version works OK with old powder.def file (with scale:2). All versions are manually compiled.
I can assist you with backtrace, which was printed by glibc.

If you can provide any logs to me I may be able to find your problem. Sounds like an invalid type conversion causing it to crash seeing as the only difference is an integer being changed.

EDIT:
Does both 32 and 64 bit work fine in scale:1 mode?

Yes. Both 32 and 64 bit versions works fine in scale:1 mode.
Backtrace from 64 bit version:

*** glibc detected *** ./powder: free(): invalid next size (fast): 0x000000000265c050 ***
======= Backtrace: =========
/lib64/libc.so.6[0x7fa016ac0156]
/lib64/libc.so.6(cfree+0x6c)[0x7fa016ac4a9c]
./powder[0x431f2f]
./powder[0x431fe0]
./powder[0x428647]
./powder[0x42d425]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7fa016a6d9ed]

(I can send memory map only to admins :o)

EDIT: Most errors in free(). Rarely, this happens sometimes:
*** glibc detected *** ./powder: realloc(): invalid next size: 0x0000000002198650 ***
======= Backtrace: =========
/lib64/libc.so.6[0x7f6b6788c156]
/lib64/libc.so.6[0x7f6b67891864]
/lib64/libc.so.6(realloc+0xf0)[0x7f6b67891bc0]
./powder[0x432d74]
./powder[0x42876c]
./powder[0x42d425]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f6b678399ed]
./powder[0x401af9]

Maybe this will be helpful.