xfce4-notifyd's notification windows are placed interactively by vtwm.
I think this is because it makes the MapWindow request *before*
setting the window manager hints to declare that it's a transient
window.

The same underlying bug may result in misbehaviour with other window
managers or desktop environments, but I think window manager
configurations with interactive window placement (ie, where the wm is
configured to, by default, to ask the user to place new windows) will
be most seriously affected.

In my installation this is reproduced as follows:

 * Have running
    - nm-applet (from network-manager-gnome),
    - trayer (just to contain the nm-applet)
    - /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd,
    - vtwm with and a .vtwmrc *not* containing RandomPlacement.
 * Connect (or reconnect) to wifi, eg by interacting with nm-applet
   and selecting a wifi network.
 * Observe that vtwm wants you to interactively place the "now on
   wifi" transient notification window.  After placing the window, it
   contains the expected contents, and is withdrawn (disappears) as
   expected.

Expected behaviour would be for the notification window to appear at
the top right, without any interaction from the user.

/usr/lib/notification-daemon/notification-daemon from the
notification-daemon package works correctly, on the same system.

notification-daemon is using the same version of libtk-3.0, so either
xfce4-notifyd is responsible for the bug, or it is using a different,
buggy, gtk-3 API.  I'm afraid I don't know if there are unaffected
versions of xfce4-notifyd (or gtk).

I ran xfce4-notifyd under xtruss[1] and saw this:

19e00000: MapWindow(window=w#19E00003)
19e00000: DeleteProperty(window=w#19E00003, property=a"_NET_STARTUP_ID")
19e00000: TranslateCoordinates(src-window=w#19E00003, dst-window=w#000003CB, src-x=0, src-y=0) = <unfinished>
19e00000: --- PropertyNotify(window=w#19E00003, atom=a"WM_HINTS", state=NewValue, time=0x351A9E59)
19e00000: --- PropertyNotify(window=w#19E00003, atom=a"_NET_WM_STATE", state=NewValue, time=0x351A9E59)
19e00000: --- PropertyNotify(window=w#19E00003, atom=a"_NET_WM_DESKTOP", state=NewValue, time=0x351A9E59)

which supports my theory.  I think there can be very few good reasons
for calling MapWindow and *then* setting various WM_* properties.

Ian.

[1] X11 protocol trace utility; ITP #1087205