I'll answer your points while at the same time writing some extra documentation that hasn't been described much so far (feel free anyone to re-use this on a documentation page)
---
One of the goals I had in the ResourceLoader 2 project (or rather "Gadgets 2.0 - made possible by a few ResourceLoader improvements" as Roan and I have been calling it lately).. is to improve the user's workflow in general (in addition to just the technical aspect).
Technical aspect being the efficient loading through ResourceLoader, proper dependency support, localization and what not. Although I think the technical aspect is the main focus and main motivation for the project, the user workflow definitely needs improvements and I took some of them into account when writing the specification.
The main change in the workflow is to branch off two very important abilities away from the "sysop" user group (aka "Wiki page/ wiki user administrator"). Note that no actual user rights are removed from the "sysop" user group (neither were they ever added in the past), they were simply implied by the fact that everything was controlled from MediaWiki-namespace pages. Any gadget guru sysop is free to join one or both of these new groups as soon as we're live.
- The first ability to be available independently from sysops is the ability to maintain gadgets. This was annoying so far because, like you say, the gadget resources are stored in a pseudo-namespace prefixed by "Gadget-" inside the actual MediaWiki-namespace, which is (and should) be restricted to translators and sysops. This made it impossible for anyone expert and trusted with JavaScript to easily help out. Often leading to pending "
{{editprotected}}" messages on MediaWiki_talk-pages by users requesting that a sysop copies and pastes the latest version from page X.
- This is now solved by having gadget resources live in their own "Gadget"-namespace. Among many advantages is that they can be easily filtered in Special:RecentChanges (What changes were made to gadgets recently), as well as the ability to grant users access to it (users that know JavaScript) without them having to be super well known by the community and becoming a "sysop" and all.
- A new user group "Gadget authors" was introduced which grants the
gadgets-edit user right (=ability to edit in NS_GADGET)
- The second ability is the ability to manage gadgets. Meaning that a set of js/css pages in NS_GADGET will be available as a bundle in everybody's preferences. As well as the ability to enable something by default (which is not something a developer should be needed for). This is improved/made possible by two things.
- Special:Gadgets (Gadget manager): The management of gadgets is now much more intuitive and doesn't require any knowledge of some obscure syntax.
- A new user group "Gadget managers" was introduced which grants the
gadget-definition-* rights. This is what grants users the right to use the Gadget manager.
Note that the "Gadget authors" and "Gadget managers" user groups don't actually exist by default, they're commented-out examples when installing the Gadgets extension. Any wiki is free to configure this in any way they like. For instance, WMF may chose not to have "Gadget managers" and instead grant those rights to the "sysop" user group (Introducing only "Gadget authors" as a new user group). Of course separate user rights and groups can still be configured on a per-wiki base would a wiki wish to have a separate "Gadget managers" user group.
Also note that although a Gadget author is not able to enable a gadget by default, there is no difference between editing a JavaScript-page of a gadget that is or isn't enabled by default. So any Gadget author is therefor able to modify scripts that affect all users including anonymous users (assuming there is at least one gadget set to be enabled by default). This is why we shouldn't put the bar for Gadget authors too low. In order to attract new developers the bar should not be too high either. Previously the bar was being a sysop, so I'd say it's a significant improvement already.
If a Gadget author wishes to develop/test a gadget, they would previously do this on a subpage of their user page (i.e. User:Example/Gadget-Foobar.js). This made collaboration hard (since nobody else is allowed to edit that user subpage), as well as sharing. By having them in the Gadgets namespace one can create a set of JS pages that any Gadget author can improve and collaborate on, without it having to be an officially defined "Gadget". Anyone who wants to use this experimental bundle of JS-pages can put "importScript('Gadget:Foobar.js'); in their personal javascript.
Last but not least, development by users who have not been granted any non-default user rights. There hasn't been much improvement on that part, I do believe progress should take place in that area in the long term. However I believe right now it's more important that we finalize the existing (already fairly large) specification of ResourceLoader 2 and get it out there. And reserve the other workflow feature ideas for Gadgets 3.0, after we have experienced how Gadgets 2.0 is going to be used by the community.
The current workflow for "personal scripts" (or "potential gadgets") by users who are not Gadget authors or sysops works fairly well. They can still create as many js-subpages under their user page as they like, and have other users importScript these etc. Although these would not be loaded by ResourceLoader, the ResourceLoader library and functionality will be available there (in that they can use mw.loader.load, mw.loader.using, mw.messages.set, mw.msg, mw.html*, jQuery, jQuery UI etc. in their user subpage scripts just as if it were a Gadget in the Gadget namespace)
-- Krinkle
PS: For anyone using this for documentation, this post is not a summary of features new in ResourceLoader 2. There are many new features not even mentioned here at all. See RL/V2SPEC.
