The reasoning behind the naming 'change' for auras/displays was mostly for some similarity in what the code calls <x>. I could have kept the names, but it's one of those things that'd require a lot of changes to the localisation strings. That said, the Sources system isn't called Sources in the code, so I guess this is kind of a moot point now
I do agree that the browser seems somewhat redundant, I've been toying around with the idea of just exposing displays on the browser directly with the auras acting as the groups (similar to your suggestion - except without any logic/positioning for groups). I wouldn't mind giving it a try, certainly.
I'd probably not allow groups to have any impact on the logic, the reason being that not even the current containers (auras) affect the logic in any way - they exist purely for grouping purposes at this point. In fact, auras themselves didn't exist until after 100 changesets into initial development - a point where everything else was already in a working state.
I certainly wouldn't be averse to making it clearer about what display is linked to what internally.
Maybe (borrowing your mockup) something like this would be in order, whereby displays that are linked to each other by their activation criteria (as added in the latest release) would appear in subgroups under the selected aura together. You could then rename the subgroup if the name is too vague (it'd be based off of the first 'Main' trigger, so Unit Aura in the example), and change the colouring of the group while you're at it. To edit a display you'd simply click on it.
Groups containing groups would probably be a no, since the aura/group hierarchy shown
should suffice, for instance you could name an aura "Buffs" and name each individual group after the buffs those displays are responsible for tracking.
As for things like exporting/deleting an aura only being available in the editor right now, that's just a temporary thing. Right clicking an aura in a future release will have a context menu for this stuff, with the current tasks remaining as another way of pulling it off.
Thanks for the feedback at any rate