"Are you trying to display some data that a separate script is generating in a widget?" Yes, exactly.
Tried script_environment on a dummy script (also tried reqscript now; same result) and dwarfmoniter alike, adding/editing variables in during runtime, didn't work even with disable-enable or by editing variables from console before enabling dwarfmonitor for first time in current process. It looks like the environment dwarfmonitor generates and the environment console generates are different. (Adding something to BASE_G obviously failed too; wildly speculating might be that they're on separate C lua states).
As to why separate, there are couple reasons why not put all the code in the widget itself, but the chiefmost of them is sharing and multi-user extensibility of the codebase; atm I'm thinking of working off a paradigm that - on first call opens and edits a widget in dwarfmonitor just before the last line (and edits json as needed) - the widget is given things to render in a file of scripts to require - hereafter new things are added in that file whose presence is checked on enabling.
Another reason is dfhack.timeout being null and lack of persistent configuration storage, and what those imply. Now, while I use it fairly often, I guess timeout could be worked around via render reading in-game ticks. Things that take input like constructmultiz though require somehow matching display to internal conditions. I also don't know what else I might find missing for dozen other ideas, such as df.historical_figure.find, which would be absolutely necessary for, say, importing the widget displaying spouse from relations-indicator.