Apologies for the delay in responding.

After some more intense investigation on my end, it would appear to not be a bug as such, more intended behaviour but un-expected behaviour (from the user standpoint) from tiling, as follows:

Using the following bitmask for window states:
STATE_MINIMIZED              = 1
STATE_MAXIMIZED_HORIZONTALLY = 2
STATE_MAXIMIZED_VERTICALLY   = 4
STATE_SHADED                 = 8
STATE_SKIP_PAGER             = 16
STATE_SKIP_TASKLIST          = 32
STATE_STICKY                 = 64
STATE_HIDDEN                 = 128
STATE_FULLSCREEN             = 256
STATE_DEMANDS_ATTENTION      = 512
STATE_URGENT                 = 1024
STATE_ABOVE                  = 2048
STATE_BELOW                  = 4196

I get the following behaviour from all windows (my mistake in thinking thunar behaved differently to firefox etc, turns out to just be intended, but un-expected behaviour of xfwm4)

1. Start window normal: 0 (bit mask)
2. Maximize window: 6
3. Move the window: 0 window resizes to state before maximize
4. Maximzise window: 6
5. Move window to left or right to tile: 0 only an unmaximize is triggered, when window reaches left or right egde, a vertical maximize is not triggered (unsure if this is intended or cannot be avoided but I would expect the state to change to 4 and the window be tiled to the left or right)
6. Release window and then move to left or right to tile: 4
7. Move window: 0
8. Move window to left or right to tile: 4
9. Maximize window button: 0 the window reverts to normal state and the position is at the last remembered co-ordinates before the vertical maximize in step 8 was triggered. I would expect the window to maximize here (bitmask 6) as even though the window is maximized in one direction, the logical state would be normal (bit mask 0), but users would not consider a vertical (or horizontal) only maximized state (bitmasks 2 and 4) to be a maximized window. I would suggest the next logical step (for a user) from a bitmask of 2 or 4 to be 6.

The positioning of the window in this circumstance could be considered a bug, as the position is restored to the last remembered co-ordinates prior to the vertical or horizontal maximize is triggered. This results in the majority of the window now being off screen (especially if horizontally tiled at the bottom of the screen - it is nearly 100% off screen), or at the top of the screen (the title bar is now under my panel requiring an ALT + LEFT CLICK to move the window).

So from the above, I guess I am really suggesting a modification in behaviour as follows:
From step 9 above - clicking the maximize button on a window that is only maximized in one direction (bitmask 2 or 4) should change state to maximized (bit mask 6).
From step 5 above - dragging a maximized (bitmask 6) window should change state to normal (bitmask 0) as it does, but if that drag continues to a screen edge, then a state change to vertically or horizontally mazimized should trigger (bit masks 2 or 4).

Of course, if these state changes are not possible (due to limitations of some sort), then may I suggest the state change to normal (bitmask 0) should also trigger a smart placement of the window either to the centre of the screen or as set in the xfwm4 smart placement settings, preventing situations of the window being placed almost entirely off screen.

Cheers.