Trey,
I've been thinking about this for a bit, and I don't think there is a great in-ecosystem way to do this. Mostly because labscript has a fairly firm rule that everything about the shot should be known at compilation time (for convenience and nominal shot reproducibility) and there aren't any established communication channels that go reverse of the normal work flow. I can think of a few hacks that could work though.
1) Most direct, but counter of labscript flow, is to modify the transition_to_buffered method of whatever output you want to have this behavior. That method has access to the initial_values dictionary of the BLACS front panel states. You could modify the method to combine front panel values with the programmed ones here. To be sporting, you'd likely also want to save the actual programmed values to the shot file as well.
2) A more labscript flow respecting hack, but more fragile, is to hack the BLACS worker of the device you want to use the runmanager API to update a global whenever the front panel value has changed (so modify program_manual). Then use runmanager globals to sum things together and compile as normal.
3) A not perfect solution that works now (I think) is using the function runner device to use the runmanager API to update the globals for the next shot to be compiled based on the state of BLACS at the end of the previous shot.
-David