So there's a bug involved with the ability to key meshes (now including clipping masks) that I wanted to bring to your attention. I also figured while I was here I'd make a few feature requests that I've been mulling over. I posted about this bug ages ago and never brought it back up because I was stuck in 3.8 for a while until 4.1 got curves (I emailed Nate back about that but not sure if you got it - great job on that in the event you never saw my response, and thanks for emailing me about it! Also cheers for being the best damned dev team ). I figured with how many changes happened in the upgrade to 4.0 that this would either get fixed or the underlying structure causing it may have gotten changed so much that it didn't exist, but it seems to have gotten worse lol. so here goes:

BUG: Invisible Mesh Key
Occasionally the key icon on the Tree view that allows you to manually key a mesh will not be visible (similar to how it looks when the mesh is set to off, or how a non meshed attachment looks inside of a slot). The solution to this has always been to move a vertex on the mesh, ctrl+z to undo, and that would make the key icon reappear. Alternatively you could turn on auto-key, or if you noticed it before making changes could simply flip the mesh on/off. It was a pain in the ass but nothing too awful. In 4.1 now this issue appears to have extended to clipping masks as well. However, there is NO WAY to make the key icon on clipping masks appear. The only work around for this is turning on auto-keying. So I mean, again not the WORST thing ever, I can work around it, but since I don't really use auto-key too often I do run the risk of accidentally leaving it on afterwards, and its just somewhat awkward. If it's any help my file sizes are on the large side (no single element exceeds 4096 in any direction, but some do push this).

FEATURE REQUEST: Pack Settings bool to separate skins to their own texture sheets.
So I have some skins for animations in my game that use like 90% of the base skin of a character, but the added items take up a large amount of space and add multiple textures. They also are used infrequently enough that I don't need to be able to actively call them whenever. I've taken to exporting both as completely separate skeletons which makes for a bit of an obnoxious pipeline (and it means that we basically double up on that 90% of the texture that's used in both). If these alternate skin elements were isolated to their own texture(s) rather than being mixed in with every other element of the base skin texture sheets it would allow the different skeleton exports to share textures in the worst case or just allow me to run one skeleton in the best case (I actually have no idea if a texture sheet is never called if it's the same as if the sheet never existed in terms of the weight of the skeleton - would love some info on this). As mentioned above in the bug my files are on the large side, so if you'd like some examples of where this issue pops up I can post some export examples.

FEATURE REQUEST: Saved Selection Groups (or just more organization tools in general)
I would like a way to save a set of bones/meshes/slots/whatever so I can easily grab it again whenever. This would help a lot with any time I need to reuse more specific elements from an animation, or just want to edit certain areas quickly. Really any and all organization tools are always a great benefit! (Saw someone else ask for something similar in the animation editor in another thread, I'm all for that as well). Would be great if these type of organization tools could be stored as simple buttons we could click inside of a folder, similar to how events/constraints/skins are stored currently (just w/ different functionality obviously).

FEATURE REQUEST(maybe??): Changing Parent Bone AFTER Animations while retaining world pos of children
So I'm sure this isn't a bug, and I'm curious also if maybe I'm just doing something wrong and if there's already a way to do this (hence maybe not a feature request either). Currently though if I want to add a new parent bone to bones that have already been keyed in animations, it moves the child bones to new locations from the ones they were originally keyed on. What I'm curious about is if there is a way to add parents after the fact while keeping the world position of the original bones (where as currently it appears to treat their keys as local or parent associated). I understand the bones are all inheriting a lot (like if there's rotation suddenly from the new parent) but my use case is basically just acting like a new center pivot for the children bones, but the subsequent results are so different per bone that I feel I'm just not understanding something.