XControls work just fine... if you dance with them the way they were intended. *head bang*
If you don't want data to be saved, one way is to not put it in the State data. If you only need the data in the facade, add a shift register. But if you need it lots of places, put a global unique ID (GUID) in the XControl's state data, something that never changes after creation, and create an LV-2 style global with a lookup table from the unique ID to the data.
You can create GUIDs on any LV OS using:
LabVIEW 2017\resource\Framework\Providers\API\mxLvGenerateGuid.vi
Changing the state shouldn't cause the VI to need to be saved unless it needs to be saved. So, yes, sure, in the IDE in a directly called VI, yes, changing state dirties the VI. But obviously that doesn't happen in a built app. AND, importantly, it doesn't happen in the IDE for any dynamically loaded VI (unless you are adding the 0x1 flag to track changes, in which case you get what you requested). If you're loading the hosted VI into a subpanel, that means you're working with it by VI Reference. So load it using Open VI Reference (without the flag) and the problem of being prompted to save should go away.