Bug report: admin bar links to wrong wp-admin URLs (mapped domain, possibly also SSO problem)

NB: I see that there have been some other similar posts on the subject, but it's not clear that those cases are exactly the same as this one since they seemed to be opened a while ago. Apologies if this is a dupe. In any case, maybe I can shed a bit more light on the problem.

Somewhere between v4.3.0.4 and v4.4.0.1, links (eg to edit post) in the admin bar (ie, as seen from the mapped domain) have somehow gotten broken. Note: Our site is set to force SSL for login and wp-admin, therefore we force the original domain for wp-admin in order to avoid SSL certificate CN mismatches.

Example:
• the original domain is original.domain.com
• domain mapped.domain.com is mapped to original.domain.com/mapped (we're using the subdir mode of WPMS)

With v4.3.04, the admin bar edit link points to https://original.domain.com/mapped/wp-admin/post.php?post=87&action=edit, which is correct and works just fine.

With v4.4.0.1, the admin bar edit link points to https://mapped.domain.com/wp-admin/post.php?post=87&action=edit. Immediately this is a problem for SSL because although the plugin should redirect to the correct URL, the browser will first hit the CN mismatch (we happen to have a wildcard certificate, but in the general case this will break, especially if the mapped domain is completely different, which would be the general case).

Clicking on this link bounces me to a login redirect, which is weird because we have SSO/cross-domain autologin turned on, so there may be a bug related to SSO also.

After logging in again, I am redirected to https://original.domain.com/wp-admin/post.php?post=87&action=edit; note the missing site slug, the correct URL should be https://original.domain.com/mapped/wp-admin/post.php?post=87&action=edit

This might be one bug, two separate bugs, or two related bugs. This is a complex plugin and I am overcommitted right now, but I will help diagnose the problem just as soon as I am free from my current task.

For now, I have reverted to v4.3.0.4 on our production site, but I have v4.4.0.1 installed on our staging site if any of your devs want to look into this. I will assist in debugging where I can.

This is an urgent problem to solve because of the recent XSS fixes contained in v4.4.0.1.