Mike Caulfield reports, after watching four dozen or so people play around with federated wiki in various contexts, I think I can identify the biggest problem: loss of write context, and the sad cycle of errors that result.
✔ This seems to have been largely solved by having operations that change origin open new tabs.
Scenario
Logged in; origin at left; browse to things they like; double click to see author; origin page shift.
Browse more; add pages; get forked-to-local in other's site; don't notice. keep adding; stuff forked to local elsewhere.
Is something wrong? Site keeps writing so it must be ok.
Somethings is wrong; back to origin in another tab; new neighborhood; what? Then try to drag local work from the site they don't own to the site they do.
Except local pages on remote site are not draggable to their own site. Due to site-indexing of local storage.
If you try to drag them to your own site it resets the origin page to the site you don't own. This is a bug caused by improper href for the flag of recently forked pages. issue 
Compounding
Sometimes this is not noticed causing more confusion. The pages now exist in a limbo, unable to fork to server.
Also, they now have this other site in their browser bar memory, so when they go to use autocomplete to get to their site (which most do) it may autocomplete them into the other person's site, and the cycle starts again.
I honestly think I've seen everyone that has used federated wiki for any length of time get lost in this way. (*I've* even gotten lost in this way myself, which is saying something).
Root Cause
After some thought, I've realized the biggest problem is that the write context and the browse context are intertwined. On almost any other system, when you log into a write context you stay logged into a write context. If I log into pinboard, I browse where I want, knowing that I'm posting page bookmarks to that pinboard account. If I log into tumblr and browse other tumblelogs, my write context stays my account, and if I have multiple blogs it asks me when I hit repost whichof my tumblelogs I want to post to.
I don't know if this is fixable -- it is made complex by security blocks, cross-site scripting issues and by having multiple sites with no connection or knowledge of one another. I don't know what the answer is. But as I was watching yet another student do this in front of me in office hours, I realized how many problems and frustration have a shifting write context at their root and thought I should pass it on. I get emails from students who say "I I logged in and tried to do work on Friday but it looks like you own all the pages now? It wouldn't let me write." etc. It's usually that they've auto-completed their way to my site, etc.
Solution?
Links are benign in federated wiki except for the page flag that takes one to a new origin, the root cause of the confusion described here.
An alternate behavior would be to simply add the remote sites welcome page to the right of the page in question. This is already the click behavior of flags in the neighborhood.
The footer contains another link that will change origin. This much less used feature is so labeled so may not as easily confuse. It should be marked with the external-link icon and open in a new tab.
The page flag anchor href should remain as is since it will be examined when a page is dragged to a new tab or factory item. The javascript click handling ignores the href.
Inconsistent behavior between sites will be noticed since not all sites will be serving an updated copy of wiki-client.
Drawback: reloading from the origin is a convenient way to discard unwanted neighborhood. This is especially true looking at Recent Changes.
Drawback: reloading from the origin is a convenient way to discard unwanted left hand pages from the lineup. Is there a better way?
Plan B: The javascript could just open a new tab if there is a change of origin. Would this be too complex? Probably.