Thanks, Steven, for going into the details.

BUT: Juicebox proposes to copy the embedding code "as is" into the HTML page (it even provides a separate button for copying)! Which doesn't mean to modify the text, does it?

Nevertheless, I modified the embedded text:

src=„jbcore/juicebox.js"       ==which is the RW6 generated file==
to --> src=&quo;jbcore/juicebox.js"       /juicebox.js cannot be found
to --> src=&quo;jbcore/juicebox.js&quo;   /juicebox.js cannot be found
to --> src="jbcore/juicebox.js"           /now juicebox.js was found!

Since you refer to the browser's difficulties: I'm using the standard Safari browser, running with Mavericks, so what shall be wrong with this browser? Besides, visitors of the site will use a variety of browsers including Safari.
Firefox shows almost the very same behavior: juicebox.js was not found. After modifying the "src" statement to the latest line (see above) it runs juicebox.js, shows the line of thumbs and the buttons but leaves the main area empty (just displaying the juicebox busy icon, jbn-nav-touch-area).

Whereas Safari just shows a gray area with the jb-error-message. Going deeper I got this:

The config.xml has a size of 14.3 KB. I compared it to the config.xml of a show generated with RW5.3 & JB 1.3: same structure. There runs no local web server. The embedding page is just plain HTML (no Ajax or else) with the embedded script code for Juicebox. Do you use Ajax? Because the error "Origin null is not allowed by Access-Control-Allow-Origin" may point into this direction (web search results do show this).

I cannot send you the URL of the site. Reason: it's still not published because of the not-yet-running-slideshows.
What I could do: send you the pure page (HTML) along with the juicebox show. Please tell me an address where to send it to.

@Steven: Thank you very much for your quick response.

The RW editor can take pure code. In this case the background becomes light green to make aware of this. This way I pasted the Juicebox code into the HTML page of RW. Don't know what the RW staff has modified with their new version 6 (there are lots of other bugs in there) to touch this piece of source code when generating the index.html file.

I completely agree!

Until upgrading from RW5.3 to RW 6.0, my workflow was like this: I created all pages of the site using RW. Everything was exported to my local hard disk. Then I copied all files & directories resulting from a Juicebox show into this specific folder where the HTML page resided. Everything locally! I checked the proper functioning of the site with Safari. Pages displayed, Juicebox shows did run. Everything was fine. Now I published the whole site to my web hoster via ftp. All right.

Now with RW6: the same workflow but different results: Juicebox shows do not run now. As a quick & dirty solution I copied all index.html files (from a backup of all pages created with RW5.3) into the same position. No other change: but everything was all right now! But this plain Q&D approach fails when modifying the menu structure of the site - being reflected on each page navigation.

No, this cannot be. I described my workflow: at first everything is local under one directory. After uploading, everything is on the same domain. But now I'm going to answer your message.

Thanks to Steven's help I finally found the solution: it was an item of Safari's menu which was inactive:
Safari: "Developer > Deactivate local file restrictions" was NOT ticked. After ticking this item everything was all right: Juicebox shows immediately displayed without any problems.

Steven directed me to looking into Safari because he had had no problems with my files I had sent to him, neither with Safari nor with Firefox. Even after repeatedly clearing browser chaches and resetting the browser, there was no sign of success. After rebooting my iMac, suddenly Firefox displayed all of the shows! So the reason had to be with Safari itself. And some time later I became aware of this menu option which was not ticked but must be. I don't have a clue why this option was deactivated.

The difficulties with Rapidweaver 6 are smaller because they provide a dedicated HTML stack - this behaves better than the basis stack with text marked as code within this stack. Nevertheless, there are some oddities with editing code in Rapidweaver 6: while typing, the double quotes automatically become a double lower quote etc. I suppose this may be caused by the German localization of the operating system (Mavericks). In case of any problems I'd advise to manually edit the embedded code once Rapidweaver generated its files.

So this story finally came to a good end.