Under regular circumstances I’d blame not returning *Handled *in the *onButtonDown *here. You can’t have Up without Down preceding it.
In this case, well, buttons were never supposed to be dragged (or right clicked); the functionality behind Precise Click + draggable buttons hackaround was supposed to bedisabled (?). It looks to me as if you found a way of forcing it anyhow 
Do you have a reason to go this route? Or is this just about finding the offset?
Removing the widget from the viewport must be resetting the button’s state, it can’t fire its *Released *because it’s not *Pressed *after re-adding - a guesstimation. Now you’re getting yourself in a truly hacky territory. On the other hand, UMG does show its limitations as soon as you start thinking outside of the box.
[HR][/HR]
This might be completely irrelevant here as I might be misunderstanding something but one piece of advice I could give you is to avoid using buttons for anything they’re not designed to do. You can simulate a button by using a border (it has overridable up / down / double click) and can be dragged around. I know the automated states and sound biding are tempting at first but the buttons don’t cooperate when make them do un-clicky things.
Your last statement seems to sum it up for me:
You remove it from the viewport, it’s no longer pressed. It’s not pressed, it can’t be released.
[HR][/HR]
The canvas method I mentioned originally is by far the best approach I ever found when working with layered UIs. I regularly use several canvases nested in another *master *canvas and just switch the layer priority; within each layer, the widgets have their own Zs controlled directly. Not only can you control each layer with just an int but each widget in each layer, too.
It does complicate things a bit but once set up, it works. And you get access to the canvas slot, which more than handy!