I know that you are feature freezing soon, so I don't know if you are interested in more ideas about new things, but here are a couple more thoughts in case you fancy them.
1) Animation reset on Display reset
Let's say I have a Display triggered by a buff. This buff always lasts 8 seconds. 4 seconds into the buff, the buff refreshes giving it a new 8 seconds of duration. Would it be possible to have some way of the animation process also resetting at this point? Meaning that the start animation is replayed and the following repeated animation restarts its cycling (but the end animation doesn't play just because of the refresh). Basically, I would like the visual impression of that the Display was refreshed which a starting animation can provide. I used to solve this by making the aura hidden until 7.75 seconds remaining which resulted in the aura disappearing for 0.25 seconds every time the buff refreshed and then restarting. It would be more convenient though if there was some option to simply have the animation reset whenever the Display refreshes its duration. (It's really only with buff/debuff tracking Displays that I can see such an option having any practical use.)
2) Keypress trigger
Something that I have been thinking about for a while is that it would be cool if there was a way to manually use keyboard combinations to work as triggers. I am thinking it would probably be pretty easy to implement. It might sound useless and abstract though, so let me give a couple of examples where I have felt a need for this.
a) Taking a prot warrior as example right now: When single-target tanking I will want to use Thunder Clap to make sure that the Weakened Blows debuff is kept on the target and thus I would make a Display that brings my attention to that it's about to wear off (~ every 30 seconds). However, if I am multi-target tanking I would want to use Thunder Clap on cooldown (every 6 seconds) and I would want a Display that brings my attention to Thunder Clap every time it's off cooldown. Now, I don't think there's any way we can get PA to somehow sense if I am in a single-target situation or a multi-target situation, so it would be awesome if I, on the fly, through a customizable keypress could alter how my PA functions. In this situation: hitting, say, Ctrl-D toggles a trigger from FALSE to TRUE that causes my PA to now bring attention to Thunder Clap and Shockwave as soon as they are available, and hitting Ctrl-D again reverts to PA only letting me know when I need to use Thunder Clap to reapply Weakened Blows. I think most classes have similar situations where the way they use their skills is altered by dealing with a multi-mob situation. But in general as well, I think it would be really cool to be able to have manual triggers at your command that on the fly alters the functionality of your PA.
b) Suppose I have several long cooldowns that I want to track using PA. I find though that they clutter the screen a bit and detract from the rest of the information my other Displays are providing me with. So it would be nice to have some way of making these time counter Displays only show when I actually have an interest in the exact duration left on the cooldown. In this situation it would be cool if, for instance, while holding down Ctrl a trigger changes from FALSE to TRUE causing these Displays to show up and releasing Ctrl causes them to hide again. So a slightly different functionality than example a.
It's a pretty simply type of trigger. Most users probably wouldn't have much need for it but for heavy PA users I can see it providing a new kind of flexibility.
3) Fading out the Editor window
I recall you yourself having asked for feedback about having some way of fading out the Aura Editor window, like holding the mouse over it and pressing Ctrl. I do think it might be an issue for people that the Aura Editor covers the auras on the actual playing screen. I don't know if the size of the Editor window itself is finalized but it would be awesome if it wasn't quite as wide. In version 4 I used to keep the Browser window on the left side of the screen and the Editor window on the right side which left me with the center free. The new Editor window is quite a bit wider though so I'm finding it trickier.
In essence I think some way of making the Editor window fade to higher transparency would be a good idea (regardless of if the Editor can be made smaller or not). But would enough users do the necessary reading or testing to learn that holding down Ctrl while hovering over the Editor makes it fade away? Another way of achieving the same thing that I thought about was this: Suppose that simply hovering the mouse over the Browser window causes the Editor window to fade out. However, as soon as something in the Browser window is selected, the Editor window will of course reappear showing the selected item (until the mouse is brought off of the Browser and back onto it again). The reason I think this would work is because if a user moves the mouse away from the Editor and onto the Browser it will most likely mean they aren't interested in the current information in the Editor anymore but are instead wanting to load the Editor with new information via the Browser, so I don't think the risk of the Editor window fading out annoyingly when you are still trying to look at it is very large. At the same time, this solution would inevitable illustrate this fading out functionality for every user simply through their natural interaction with the UI; it doesn't require any reading up of hotkeys or unintuitive trial-and-error. It's a bit unconventional though so I definitely do feel that it's hard to know if it would really work as hoped without simply trying it and seeing if it feels "smart" or just awkward.
I promise these will be my final thoughts of "added functionality" since I know you'll be moving into beta soon.
Meanwhile, I am finding the alpha to really be starting to function well and I love how solid the trigger operators are feeling compared to version 4. You're doing an awesome job!