Dalai and I agreed on merging T47899 into this. The old task can still be referred to, but development took new paths that are better discussed here. We'd also like to discuss things on a broader level - the big picture for VR in Blender.
Will publish more info soon.

Added some inline notes for reviewers.
Note that I also plan to add/improve comments on API functions.

The file browser redesign which is currently in progress involved similar changes, see T62971. So the solutions chosen should be consistent across the outliner and the file browser.
This is an older screenshot, although I think not much has changed in the popovers since then:

The UNKNOWN ENUM print should be fixed with rBb7f86ff7227.
I guess this report can be closed. Although I'd still suggest to use Area.ui_type rather than Area.type for this add-on.

• Merge branch 'master' into arcpatch-D5325
• Fix mistake (was unlikely to ever cause issues)
• Minor cleanup: Variable declaration/definition order + use const

Please create a proper bug report with all requested information given. You'll also have to speak english here, there's not much we can do for you otherwise.

Previous comments are correct. This seems to work as designed. Closing the report.

In T68448#749314, @William Reynish (billreynish) wrote:

Could do that, although then they would overlap with other editors and content.

Right, we wouldn't want to be too intrusive for info or low-importance warning messages. A bit of color and animation can be handy to draw the users eye here, but an overlapping popup would be too much.
OTOH important messages like errors should be intrusive - when we get one, the workflow was already disrupted, the message just exposes and explains that fact. So IMHO a popup is fine here.

Since this gets into the idea of repurposing of the info editor, I'd recommend checking out what we've considered during the UI workshop: https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Info_Editor. The full info editor should always be reachable from the status bar (e.g. a More button could spawn the info editor in full screen, or as separate temp window). So basically the status bar would be the short version of the Info Editor, the latter containing all details.

[Off topic]
It's not that I expect a big performance gain from a separate drawing thread. But we can avoid overhead of the main loop and OpenGL context switches using a separate thread. Currently this gives me about +11 FPS in the classroom scene. The other reason is that OpenXR runtimes perform blocking calls for frame synchronization, also blocking the rest of Blender. I've also outlined the reasons here: https://devtalk.blender.org/t/gsoc-2019-core-support-of-virtual-reality-headsets-through-openxr/7614/28.

Did a few more tests, that is, running Blender and letting it execute gpu_context_active_matrix_state_get 1.000.000 times. Either accessing the matrix state as a static or a static thread_local. Again compiled on latest MSVC. I ran three passes.

Just checked Clang ouput with optimizations enabled (O1 and higher), and it also solves it without the extra function call:

getNumber():                         # @getNumber()
        movsd   xmm0, qword ptr fs:[number@TPOFF] # xmm0 = mem[0],zero
        ret

I find it a bit hard to reason about this. There are some older post describing why it is or was slow (https://stackoverflow.com/questions/13106049/what-is-the-performance-penalty-of-c11-thread-local-variables-in-gcc-4-8, https://software.intel.com/en-us/blogs/2011/05/02/the-hidden-performance-cost-of-accessing-thread-local-variables/). Newer posts seem more optimistic (https://stackoverflow.com/questions/32245103/how-does-the-gcc-thread-work). But ultimately, this is of course heavily platform/implementation dependant.

• Cleanup: Remove unnecessary call & var

• Share code of new functions in resources.c

• Cover all UI_GetTheme calls in draw manager

Yikes, indeed there are quite a few more calls to be covered. Wrote this while traveling so wasn't too attentive...

Note that there are two vastly different meanings of "sticky keys". On Windows, it's the name of an accessibility feature, where pressing a modifier key would leave it pressed until... pressed again I think? (Please correct me). I guess this is what's being referred to here. For us, and I'm not sure if we've taken the name from somewhere else, sticky keys usually refers to the ability to differntiate between a tap, and a hold of a key.

I guess this should be available everywhere in the editor. @Jacques Lucke (JacquesLucke) you were the one doing changes here, did you change this intentionally?

In list view, it would be very nice to support shift-clicking to select in-between, ctrl to extend selections.

This already works. Shift selecting extends, Shift + Ctrl fills. I guess the extra Shift is needed because Ctrl only is used for renaming. I guess we could check if there's already a file selected as better differentiation.
All in all the selection could use some rework. E.g. you still need to use RMB to select folders. Can do that after this redesign.

In T67164#731961, @Brendon Murphy (meta-androcto) wrote:

hi, there's issues here with the timelne. It's still a stand alone editor type in start up.

Versioning is a bit difficult for this. Can't avoid some tradeoffs.

Current state of the implementation looks like this:

TIMELINE is now DOPESHEET_EDITOR with its mode set to TIMELINE. The Add-on may be better off using the Area.ui_type enum though (see https://docs.blender.org/api/current/bpy.types.Area.html#bpy.types.Area.ui_type), which is the same enum used for generating the regular editor dropdown and includes all the editor sub-types.

We've just talked about this on chat.blender.org, so leaving a quick comment here: VSE should probably get a way to display the "Adjust last Operations" panel (Operator redo). That way operator settings could be tweaked after the operation. Added item to the TODO list, T55366.

I'm probably the one who did most changes for 2.80 in relating code. And I didn't remember ever seeing special treatment of split regions, which made me wonder how this could ever work before.
Turns out we added the AZone's during region size updating, at a point where the prev region was temporarily using a winrct of both regions combined. So of course a single AZone spanning both regions would be added.