Dear PID, broc, Andrew, et alia:
Yes, things that used to work fine don't anymore. What doesn't work at this point is pattr recalling its value when in a subpatcher.
Pattr (in parameter mode) does not initialize properly within subpatchers. On the top level of the patch, everything is fine. In a subpatch, however, nothing is initially sent out when the device is loaded, or if the "Initial Enable" option is on, the initial message is always set out, even if the current value is different (banging the pattr proves this).http://dave.rhymeswithart.com/pattrParamTest.zip
This is a little device I threw together to make testing this easy: 4 pattrs (one set to each data type) on the top level setting message boxes with a button for easy pattr banging, and the same thing encapsulated in a subpatcher. The device was saved with all message boxes blanked so anything showing was actually loaded by Live. With very rare exceptions, nothing is typically output by the subpatcher pattrs. You can set data through the device, save your session, and then reload it. Nothing will be output in the subpatch, but clicking the button will show that the data was stored correctly.
Addtionally, even if these pattrs are banged at load time (either triggered by a loadbang or the last parameter, etc.), they don't know their contents yet and simply output a zero. Banging them later, however, does work, as phattline indicated with his delayed loadbang approach. His part about pattr not working with an argument is not correct, but I don't blame anyone for being a little superstitious with something this hairy to track down.
A work around for now? With the device you pasted, pid, de-encapsulate the M4L.api.DeviceParameterRemote, and then de-encapsulate the enclosed M4L.api.SaveLivePath. With the pattr now on the top level, it should go back to working fine.
So yes, this is a seemingly new bug, but definitely a bug. Any confirmation from official folks (and anyone else who can reproduce the issue) would be nice.