OK.. ok.. I have thought this through thoroughly and looked up the Win32 API and implementation that make the recycle bin happen.
SHFileOperation (the actual function that moves things to the recycle bin) does not support network paths (mapped or not) when the FOF_ALLOWUNDO flag is set (recycle). The trick you found is a workaround that Microsoft might very well fix any day now. It leaves the API broken as you can see if you read all of the posts on the workaround page you provided.
Lets start with logic.
Look at the root of any local drive you have. You will find a folder called $Recycle.bin. When you delete a file, the windows explorer uses this folder to move your file there instead of a real delete. It does not move files from D: to C:\Recycle.Bin.. etc.. the mechanism is made to work against a single volume. Even though there is some complexity in renaming the original file and keeping track of the date/time of deletion, it is as simple as that.
When you are looking at a network share, you will NOT find a recycle bin folder and windows (rightfully so) will not make one for you. Can you imagine if every admin had to keep track of all of the crap that each user deleted on their share? Microsoft could have very well made this work.. but they chose not to.
You might get this to work but there are two basic problems here.
Problem 1 is that it Microsoft never intended to have recycle bin access from cmd.exe. Even the utilities that allow this call into the shell API (aka explorer).
Problem 2 is that this mechanism will NEVER work correctly from a network share even if you can demonstrate cases where it does "work". Until you see a $Recycle.bin folder on your mapped network drive.. something outside of the tested code path is happening.
I hope that someone else can give you a workaround but unless you "roll your own", I think it will be shoddy at best.
Good Luck! I mean it!