Hey, just fiddling around with toggling layer visibility/locked status.
Was a little bewildered when I toggled the currently selected layer to be locked that it triggered the entire artboard to be de-selected.
I'm not sure if locked components should be selectable.
But if not, I guess my expectation is for the parent layer to become selected when I lock the currently selected layer.
Thanks for the report and clear statement of your expectations!
Ryan and I talked about this, and we're not satisfied with the current behavior either.
The current surprising behavior is the result of two seemingly reasonable decisions:
However, the logical consequence of these two decisions feels surprising, and we're not sure what to do about it.
We did think about changing the selection to the "next" element (the same behavior that happens now when you delete an element), but if we do that then you can get into trouble using hotkeys to cycle through the visibility modes.
That's an imagined problem right now (since we don't have hotkeys that cycle through visibility modes), so it may be the best solution.
I'd like to consider some other ideas before going down that route, though.
One alternative would be to change the semantics of the tree so that it shows the "last active artboard" rather than the "currently active artboard" --- then clearing the selection wouldn't make the tree disappear.
Any other ideas?
Last active artboard sounds reasonable to me!
I don't fully grok the internal model, so if that change doesn't break existing semantics/expectations elsewhere in the interface, then it seems like a win.
I would consider to keep the locked element selected because of the following reasons:
Agree that cycling is weird. Showing the tree of the last selected artboard addresses this and the "user still has a reference", no?
We decided on "locked" meaning "cannot be selected" since this allows people to "click through" things and select stuff that is behind it. Having the tree allow selection on a locked element but not allowing the visual element to be selected is inconsistent.
Some other programs do allow it, sure, but that alone is not compelling reasoning for us.
Would the "show last selected artboard" solution meet your needs?
If not, can you elaborate more?
A selection indicates that an element can be modified—either in layout or style. But a locked element explicitly can't be modified. Showing it as selected is inconsistent behavior. It's suddenly not clear to the user what actions are available.
Maybe there's a setting that I'm not familiar with, but the default behavior in both Sketch is to deselect the current element when you lock it. Photoshop's not a great analog, because it doesn't have selections per se—you can highlight a layer in the layers panel, which indicates what will be modified by direct manipulation actions. But transforms are a mode in Photoshop, which is a different beast altogether.
I guess there is a slight misunderstanding. Let me try to correct myself. Sorry about that.
The confusing part is that the entire layer tree is disappearing after a selected layer is locked. I have to reorient again and realise that I have to select the canvas to see the layer tree again.
And yes, you are right, Ryan. Locked elements on the canvas shouldn't be modifiable. But a problem occurs when I try to understand what state the interface and its elements that I constructed are in. If I try to select a locked element I get no feedback or indication that this element is locked. Neither in on the element nor in the layer tree, meaning I have to go through all the locked elements in the layer tree by unlocking and selecting them to figure out which one it is.
I was referring to Adobe Experience Design which indicate state of the selected element with a lock icon that also acts as an unlock button. Indeed Photoshop is a different beast and most of the behaviour there is not favourable, in my opinion. At least in the context of interface design.
I hope I could clarify my point a bit. Sorry again for the confusion. 
Ahhh, tree visibility. Got it.
We settled on the current behavior as a way to help keep the tree view manageable in complex files. When you lock an element, it collapses in the tree view.
I think it's TBD as to whether that's the right behavior—but for now you can always uncollapse the locked element by clicking the triangle next to the element name in the tree, which will also make the element visible again.
This is something that doesn't really have an analog in Sketch or XD because neither app has true relationship hierarchies. You can nest groups. I'm not sure about XD's behavior, but in Sketch a locked group has the lock icon next to its layer (as do locked elements in Subform). But things within the group don't also have lock icons.
Would it be better if every child of a locked element (and grandchild, etc) also displayed a lock icon?
In the November Beta, Adobe introduces Layers to XD. And there it works a described before. As I select a locked element in the canvas it is selected in the layer tree and vice versa.
Regarding to the question about children behaviour it might not be necessary to show the state on each child but only on the group element. But I guess the child behaviour is a personal preference.
The overall behaviour of an locked element is something that I see related to "immediate feedback" which is very well explained by the examples and talks of Bret Victor. Meaning it takes away the guess work by figuring out the relation between different representation of an element in an interface (element in the layer tree <--> element on the canvas).
Does that make sense to you?
I'm still not sure I understand the exact behavior that you're looking for...