codestyling

define( ‘WP_CONTENT_DIR’, dirname(dirname(__FILE__)) . ‘/wp-content’);
define( ‘WP_CONTENT_URL’, ‘http://localhost/wp-content’);

Defining the url without any need to be different (dir sharing is suitable enough) you just higher the barrier to plugins to fail and you would create mixture of SSL and none SSL content even in admin area!
Sure, I can handle such artificial cases. But in my opinion this is far away from reality.

BTW: symlinking only the shared content folder into the separated installs.

@unsalkorkmaz: WordPress 3.5.x is working out of the box with either SSL or none SSL requests out of the box. I have a local testsystem with multisite and several subdomains and a self certified wildcard certificate and can freely choose to visit admin and frontpage with SSL or non SSL as I need it at any time.

I did only setup 2 vhosts one configured to post 80 (non SSL) and one to port 443 (SSL) and both using then same document root.
This should be the case at providers too or can be at least configured to the same document root.

Thats it. Now the WordPress installation is callable at any time with both options. if you want to avoid non SSL entirely, just place a .htaccess rule to redirect any http:// call to https://

get_site_url() delivers the option save during install at the wp_options table as siteurl. This may not match with your current blog/wordpress url and thatswhy it will be handled as not same origin.
I have this case currently reported by a live blog too, where the user first installs the blog not using www. but changed it afterwards to have www. within the urls by changing the urls at settings page.
But this doesn’t update the siteurl option in database and will lead to that “not same origin” detection.

I will check those cases more specific with next update but afraid, that this is a wp core bug too.

I can’t analyse the issue completely. But you are using

http://single.wp/

as your domain and I assume, you did configure a local vhost within Apache doing so.
My plugin currently requires protoype.js library which have been removed from WP since WP3.5 and replaced by CDN loading if required via google.
I did replace that routing in terms of my plugin with self maintained versions of protoype.js (script.acoulo.us) delivered at my pages as usual.
The WordPress own jquery version calls at last statement the jQuery.noConflict() but I have seen replacements from jQuery within wp-includes folder, not having that last line at supported other users.
The did replace the WordPress bundled files with their own newer version but didn’t realize, why WordPress is doing so.

So in total: it could be a url request issue for the prototype.js files (should be visible at firebug with 404 delivery) or could be a jquery modification at your installation.

Not explainable for me. Did you also try another browser than chrome too?
There is no reason why it doesn’t work, except the PHP environment can’t perform wp_remote_get() calls properly or the ajax requests are send to the wrong WordPress file (path problem).

How did you setup your local server (OS, HTTP Server, Folders etc.)?
What in detail meens “does not work”?
I’m using it since starting with this plugin always at remote and locale installations, even using Windows XAMPP and Windows Subdomain installs.

Because this folder comes first during the dir scan and contains at least one *.mo/*.po or *.pot file. Because CSL can’t analyse the path because it’s created by function call and not by a constant, the only chance is to take that folder containing translation files.
If there are 2 of them (whatoever reason?) the first found will win.