Here's a proposal doc for how the annotations could work:
https://docs.google.com/document/d/1HvogywJQPMHQPKp1oUMGotdIGY-7gM2TBhfcFZPkOZ8/edit?usp=sharing

@Sergey Sharybin (sergey) Agree with some points, but strongly disagree with many of the rest (particularly some of the larger high-level concerns raised).

Most of the problems should be solved by rB3721b857c697e3b9bc369f3b3afa0a6894e0584b

IIRC, Shift-O is currently used for "Sample Keys". That said, maybe we don't need a dedicated hotkey for it (and the Smooth Keys - Alt-O) operators, as I don't think they're actually used that much that they necessarily need the hotkey.

It will be removed - in due course :)

@Daniel Lara (Pepeland) (pepeland) I'm not really arguing that you don't need AA to be applied to GP strokes. What I am wondering though is whether we really need the settings to enable it in the first place. IMO, it seems that you really shouldn't need to be worrying about this at all, or if you do, it's mainly a quality setting that ends up being more of a render setting (like how you can control AA strength in normal renders)

As I mentioned here, I'm not convinced that this should be a user pref setting. This is something that affects the look of rendered output (and should stay consistent across different workstations). For this reason, IMO it'd be much better if this was some kind of per-file/scene render setting - in fact, is there any reason why we don't just reuse the standard anti-aliasing settings in render settings if it really is necessary to have control over this? Conceptually, these are practically similar issues, so I don't see the need for a separate setting for this?

Hmm... why is this even a user-pref option when it will affect the final quality of how strokes will get rendered? At this point, GP objects will mainly be used for creating 2.5D art. Therefore, I wonder why you don't just reuse the rendering anti-aliasing settings instead for this even?

The crash happens when you've got ASAN enabled on Linux. It only crashes in release (not debug) builds.

Unassigning from self - this low-level requires a bit more trickery than I have time to explore right now.

Calling the OBJECT_OT_duplicate operator directly seems to work ok.

Just a note - if the performance woes are due to animation editors (specifically the timeline), I've got some plans already for optimising a bit there. I was going to try to work on that this week if time allows. (Specifically, my plan would also help resolve some other issues animators were having with functional side of things, by deduplicating a lot of the calculations that go into drawing the keyframes).

Checking the code, the addon needs to be modified to read the original pose from evaluated data (e.g. context.depsgraph.id_eval_get()). Most likely, we should just modify get_current_pose() (or the store_bone()) inside it.

This is a blocking issue for Spring animators - particularly as @Hjalti Hjálmarsson (hjalti) needs it to do facial animation soon.

@Daniel Paul (DaPaulus)

• Auto calculation is a separate topic - it's not related to the drawing.
• The main interesting features of that mockup are the explicit display of the start/end frames. Otherwise, it's actually pretty much just the standard display
• "Tangent editing" or just general motion path editing is actually a lot harder than it looks - especially in everything other than the most basic case. Unfortunately, you can't just support that simple case, as people will want the others too. Anyway, again this is separate from the issue of just getting drawing code working

Probably this wasn't ported yet in the cow taskforce... (T54829)

Fixed in rBf7c75e8bd7e77829a8bcbab91827552e97821e8e