This is my revision.
Please let me know if I need to change what the text says or if its good to go.
Comments and critique welcome.

Had to make changes to support lists with categories where the items in a section overflow to the next column

Windows cursors getting a bit more love. Every one now has three sizes (for differing monitor DPI). "Open hand" got edited again.

@Peter Fog (tintwotin) I feel you...

Without these Annotation Tools exposed, the Annotations aren't of much use in 2.80. Why not expose them for now, and make it at least usable, until a proper toolbar is implemented?

We should not add those buttons. They are insanely clumsy to use, because you can only draw one stroke at a time.

It is possible to add the Annotation Tools to the Sequencer Sidebar, but the functions do not seem to work:

@Duarte Farrajota Ramos (duarteframos) :
Are file names hardcoded? Should I use the same for export, or am I free to name them more sanely?
I was thinking of appending suffixes for size like L or S, and name all families before variant...

Are file names hardcoded? Should I use the same for export, or am I free to name them more sanely?

Mostly cleanup. Removing a couple cursors. Some work on Knife and Open Hand. Removing cursor that was going to be used for drag and drop because that needs a separate rethink.

Mostly more changes to the knife cursors, based on feedback from @Duarte Farrajota Ramos (duarteframos) (Duarte Farrajota Ramos)

@Duarte Farrajota Ramos (duarteframos) -- I'll try to do a few mockups in the coming days, and post them here when ready.

@ThinkingPolygons (ThinkingPolygons) - Just an additional option to choose the regular "arrow" cursor would be good enough, I think.

I see, fair enough.

@Duarte Farrajota Ramos (duarteframos) - Are these all the required cursors for now?

In D5197#119840, @Harley Acheson (harley) wrote:

I didn't know that edit mode was an issue. So I'll aim for allowing a choice of different cursors for each of edit, paint, and sculpt. With paint and sculpt getting additional choice of "none".
Once I have that ability in the patch we can then see if we need to improve these cursors, add more, etc. I'm running out of ideas with them so it might need a fresh set of eyes on it. Especially eyes that spend a lot of time editing, painting, and sculpting.

Will do, I'll be glad to help with my limited knowledge.
I'll probably be a bit busy next couple of weeks so I can't promise much, but I'll try to squeeze in something. After that I'll probably have some more free time.

@Duarte Farrajota Ramos (duarteframos) : ...but I do enjoy it as a hobby.

Actually, I think I understand. When squashing the slider beyond its minimum size, we would expect the timeline to stop moving, but it does not. Still not too convinced that this is a bug.
@William Reynish (billreynish) So by "Left scrollbar slider" he means this guy:

Although it's still not 100% clear to me what the issue is, it seems like a minor papercut, and not necessarily a bug? Also, when I try "squashing" the slider, I get a different result from the video. Could you re-confirm that whatever the issue is is still an issue in the latest build?

@ThinkingPolygons (ThinkingPolygons): ...looking for a way to change the cursor of the edit mode...

Well not really my area of expertise either, but I do enjoy it as a hobby.
Either way I made them in Inkscape, so they are available as vector graphics, should scale well to other sizes, though readability at lower res may dictate manual per-pixel adjustments.

In D5197#119836, @Duarte Farrajota Ramos (duarteframos) wrote:

A little nitpicking, I'm sure it is a matter of personal preference, but I think the new knife cursor is not as elegant as the previous.
Something about that 45º slanted tip looks off, like it is piercing through something. A pointier tip helps distinguish were the "hotspot" active pixel is.
I see you use mostly straight lines without curves, so some of these may not suit your style, but I've also included a few straight segments options for your consideration.
Here are a few examples, left-most is @Harley Acheson (harley) current proposal, others are mine

In D5197#119834, @Harley Acheson (harley) wrote:

You might want one for painting and a different one for sculpting? Anything else?

A little nitpicking, I'm sure it is a matter of personal preference, but I think the new knife cursor is not as elegant as the previous.
Something about that 45º slanted tip looks off, like it is piercing through something. A pointier tip helps distinguish were the "hotspot" active pixel is.

@ThinkingPolygons (ThinkingPolygons) wrote:
..as I'm seeing similar icons for the same purpose...

@Harley Acheson (harley) Will you add an interface where the user will be able to choose which icon he wants to use in a specific editor? (as I'm seeing similar icons for the same purpose)

Thanks to some feedback from @LazyDodo (LazyDodo), have lightened the color of the knife handle to increase contrast.

For Mac use OS-supplied cursor resizeLeftRightCursor for BC_H_SPLITCURSOR, and resizeUpDownCursor for BC_V_SPLITCURSOR

Just changes to allow Windows and Mac to use built-in OS supplied "IBeam" cursors in place of BC_TEXTEDITCURSOR. Looks much better and will work correctly on dark or light backgrounds as these ones are XOR.

Yep it’s a problem to mix values as Blender Light does. @Pablo Vazquez (pablovazquez) will you take a look?

The "Blender Light" theme really needs to go a bit more "all in" with the lightness....

In T67088#726249, @William Reynish (billreynish) wrote:

Indeed, however there may be issues with the single-threaded nature of Python. Node trees should be as fast as possible, by using multiple cores and even using things like JIT compiling and GPU execution. Python nodes may conflict with this.
@Jacques Lucke (JacquesLucke) perhaps you could expand on this?

Indeed, however there may be issues with the single-threaded nature of Python. Node trees should be as fast as possible, by using multiple cores and even using things like JIT compiling. Python nodes may conflict with this.

Would be also great to have python defined nodes.
Ones that run like operators.

Constraint nodes will most likely have to live on a higher level than on the bone/object level. With Blender’s architecture it’s not 100% clear how to do this. One solution is to store it on the armature level, although then they cannot be supported by objects, which doesn’t seem it would be acceptable. Other obvious solution is to store them somehow in Collections, which can contain objects and is portable. But what then happens to objects who live in multiple collections is not obvious.

How does this tie with the future of rigging? Currently it's very hard to have a base set of deforming bones and swap the rig around it, similar to what Source Filmmaker does. You can't swap Object data because the dropdown doesn't allow for that, nor can you do it swapping Armature data, because constraints and other rigging values are stored on an object/bone level, not on the armature. You have to duplicate the Armature object, along with all its children objects if you don't want to rebind each object to it. Could rigs be their own datablock or something like that? I heard stuff about rig compilation, would the new nodes even allow for that?

Hello, I've found a similar issue in the Transformation Orientations, just to be sure will be modified too, thank you!

This patch now introduces an overlay Panel per Paint mode.

Changes to windows cursors: edited vsplit and hsplit, adding scroll cursors and adding a couple alternate crosshair cursors. Removing 3 of the alternate crosshair experiments, leaving just three in total.