Sorry for the slight delay - yesterday was my last working day before Christmas, so today's been spent doing all the things I really should have done weeks ago, such as buying a present or two for my wife… 
As you correctly identified, WQS currently expects assets to live inside a site structure, although the model has been built with the intention of allowing content to be shared across multiple websites in the future. This capability is expected to make it into a later release - I'm unable to say which one at the moment.
If you want to have a stab at making this extension yourself then there are (at least) two areas that you need to focus on. The first is actually binding the assets into the site structure(s). The behaviours that handle most of the logic around web assets are encapsulated in the two classes "SectionType" and "WebAssetAspect". Content becomes a web asset when it is linked to a section with a parent-child association - it doesn't have to be a primary parent-child association. Turning a piece of content into a web asset triggers all the rendition generation logic, and so on.
The second area that would definitely need work is that of publishing. The publishing mechanism uses an "adjusted" Transfer Service that allows content located at one path to be mapped to content located in a different path. We use that to map content located below the "Quick Start Editorial" node to be mapped to the same relative location below the "Quick Start Live" node (of course, the names are irrelevant, but that's what you get when you install the default site structures). However, if the content that you are transferring actually has a primary path that is *not* under the "Quick Start Editorial" node, then the mapping won't trigger, and the transfer will fail. I've only given a little thought to this, but the way I envisage solving it is to modify the logic in the WebPublishingManifestNodeFactory class so that it detects if the node it's processing is primarily located outside of the mapped area(s), and replacing its primary parent-child association with one of its secondary parent-child associations that *does* fall inside a mapped area. I'm not sure that makes much sense having just reread it, but it's tricky to describe.
Here's another stab at it: assume that the content node being published has a primary path of "/a/b/c/d" and a secondary path of "/a/e/f/g/h". Also assume that the node at "/a/e/f/" is the "editorial" website node (such as "Quick Start Editorial") and the corresponding "live" website node is at "/a/e/i/". When we publish this content node, we want the published node to appear at "/a/e/i/g/h". When generating the TransferManifestNode object to represent this content node, we have to look at its primary path and determine that it is not below "/a/e/f/". Having established this, we need to look at its other locations (its secondary ones) and see if we can find one that *is* under "/a/e/f". We find the path "/a/e/f/g/h". We then tweak the TransferManifestNode object so that it appears that the node's primary (and only) location is "/a/e/f/g/h". We then do the normal mapping - replacing "/a/e/f/…." with "/a/e/i/…." - that causes the apparent location of the content node for transfer purposes to be "/a/e/i/g/h". Once that is done, the transfer can proceed, and the published copy of the content node appears in the correct location in the live site structure. This published copy has precisely one location.
I'm still not sure if I'm making much sense. Neither am I sure that this is something you'd like to attempt. As I mentioned before, It's something we'll look at doing in the future. If I get bored over Christmas maybe I'll take a look…
As you correctly identified, WQS currently expects assets to live inside a site structure, although the model has been built with the intention of allowing content to be shared across multiple websites in the future. This capability is expected to make it into a later release - I'm unable to say which one at the moment.
If you want to have a stab at making this extension yourself then there are (at least) two areas that you need to focus on. The first is actually binding the assets into the site structure(s). The behaviours that handle most of the logic around web assets are encapsulated in the two classes "SectionType" and "WebAssetAspect". Content becomes a web asset when it is linked to a section with a parent-child association - it doesn't have to be a primary parent-child association. Turning a piece of content into a web asset triggers all the rendition generation logic, and so on.
The second area that would definitely need work is that of publishing. The publishing mechanism uses an "adjusted" Transfer Service that allows content located at one path to be mapped to content located in a different path. We use that to map content located below the "Quick Start Editorial" node to be mapped to the same relative location below the "Quick Start Live" node (of course, the names are irrelevant, but that's what you get when you install the default site structures). However, if the content that you are transferring actually has a primary path that is *not* under the "Quick Start Editorial" node, then the mapping won't trigger, and the transfer will fail. I've only given a little thought to this, but the way I envisage solving it is to modify the logic in the WebPublishingManifestNodeFactory class so that it detects if the node it's processing is primarily located outside of the mapped area(s), and replacing its primary parent-child association with one of its secondary parent-child associations that *does* fall inside a mapped area. I'm not sure that makes much sense having just reread it, but it's tricky to describe.
Here's another stab at it: assume that the content node being published has a primary path of "/a/b/c/d" and a secondary path of "/a/e/f/g/h". Also assume that the node at "/a/e/f/" is the "editorial" website node (such as "Quick Start Editorial") and the corresponding "live" website node is at "/a/e/i/". When we publish this content node, we want the published node to appear at "/a/e/i/g/h". When generating the TransferManifestNode object to represent this content node, we have to look at its primary path and determine that it is not below "/a/e/f/". Having established this, we need to look at its other locations (its secondary ones) and see if we can find one that *is* under "/a/e/f". We find the path "/a/e/f/g/h". We then tweak the TransferManifestNode object so that it appears that the node's primary (and only) location is "/a/e/f/g/h". We then do the normal mapping - replacing "/a/e/f/…." with "/a/e/i/…." - that causes the apparent location of the content node for transfer purposes to be "/a/e/i/g/h". Once that is done, the transfer can proceed, and the published copy of the content node appears in the correct location in the live site structure. This published copy has precisely one location.
I'm still not sure if I'm making much sense. Neither am I sure that this is something you'd like to attempt. As I mentioned before, It's something we'll look at doing in the future. If I get bored over Christmas maybe I'll take a look…
