In previous development paradigms for On-Premises SharePoint development we had the layouts folder to host our shared assets (scripts, css, images, etc). We could store the files in one place and have them reference-able within each site with a well-known sub path ([hostname]/[mp]/[sitecoll]/[subsite]/layouts....). This essentially meant that users could get to the asset from within any site in the farm. It also meant that permissions/access did not need to be managed within a separate location. If a user had access to the site, they had access to the shared assets in _layouts.

I'd like to see a similar concept brought forward to the tenant level within SharePoint Online (and On Prem). Maybe only tenant admins have ability to manage this library, this way assets that get deployed there can be properly vetted and a very high level of permissions needed to share these customizations across sites in the tenant.

I think this could benefit current development approaches that leverage script editor/content editor web parts, or CustomActions/JSLink, for client side customizations as well as the new SharePoint Framework (SPFx).

For example: I create a custom .js file - MyCoolWebPart.js. I upload this web part to the tenant "shared" library. I can then access the same file from different urls, like:

http://mytenant.sharepoint.com/shared/MyCoolWebPart.js
http://mytenant.sharepoint.com/subsite1/shared/MyCoolWebPart.js
http://mytenant.sharepoint.com/subsite1/subsubsite1/_shared/MyCoolWebPart.js

...and they all point to the same file. This way I don't need to copy it out to every single site collection/site.

In alot of places I've seen the root site in a web application used for this, however, this falls down with multiple web applications (i know, not an issue for o365) and/or host named site collections. There are also limitations, specifically with the Content Editor Web Part and JSLink customizations, that prevent users from being able to reference files outside the current site collection.

I know, I know...host the file myself in a custom site/server. In my current role I can do this rather easily, but I am sure there are many scenarios where this isn't as easy to do (thinking of smaller companies). Then I have to figure out a way to manage the correct path to the file between environments…I’ve yet to find a good pattern\tool\way to ensure http://mytenantQA.sharepoint.com points to http://myspcustomizationsQA.myco.com/sp/mycustomization.js in QA and when in PROD ensure http://mytenant.sharepoint.com points to http://myspcustomizations.myco.com/sp/mycustomization.js

Plus, it centralizes the assets making management/tracking/auditing/logging easier (e.g. which sites are referencing this file). And, assuming it's done using a (or similar to) a document library, you get the automatic browser cache busting when the file revs (something you didn’t get with _layouts).

In addition, since the path is relative to the site, perhaps it’s not too hard to enhance things constrained to linking to things in the current site collection (like JSLink and/or Content Editor web part)???

Finally, this could be a target for the bootstrapping JS file needed for future SharePoint Framework customizations. This might help in O365 Store scenarios for the SPFx customizations in that the bootstrapping file is always installed to the tenant, not from some random public URL that can change without notice/warning (and in theory start scraping data from the site using the deployed customization). This would hopefully eliminate some of the security concerns around ISV/3rd Party customizations with the new framework. If the bootstrapping file is loaded from the tenant “shared” library, it only got there because a tenant administrator allowed it to get there (and presumably vetted it)!

I can imagine a "shared" structure that looks like this:
http://mytenant.sharepoint.com/shared/js
http://mytenant.sharepoint.com/shared/css
http://mytenant.sharepoint.com/shared/img
http://mytenant.sharepoint.com/shared/views (.html snippets for MVC/MVVM type frameworks)

with maybe each customization having the ability to create a folder under each with the customization name or to the root directly.