"(attribute) of (sprite)" menu should show current sprite

(Disclaimer: I'm not an educator and I don't have actual significant new-user experiences to back me up; I'm just suggesting ideas based on what I feel makes more sense, from a lot of personal experience with this block.)

Since Scratch 2.0, there's been a design decision that the "(attribute) of (sprite)" sensing block should not show the current sprite. Hypothetically, that decision was made in order to clarify what the blocks intended purpose is - that is, to get the value of an attribute or variable belonging to another sprite. In my opinion, this decision is undermined by the single-sprite scenario; and, more importantly, it distracts the user from a surprisingly useful functionality of the feature related to clones.

The "single-sprite scenario" is when there is just one sprite on the project (AKA the default state of a project), so the sprite dropdown contains only the Stage, and the user is left wondering what is supposed to show up in the menu. If the menu also contained the current sprite, the user would have a very simple and immediate understanding of it: "it contains the stage and all sprites". Contrast this to "it contains the stage and all sprites, except the currently selected one" - obviously a more complex idea, and a confusing one too, when users find that the menu changes when they switch between sprites! This is the only dropdown to change depending on what sprite is selected (except for variable dropdowns when "for this sprite only" variables are present, but I feel that's somewhat more intuitive).

On my main point: Hiding the current sprite from the menu also distracts the user from the technique of accessing the original sprite's data from within a script that is called by a clone. An example helps explain - suppose you've encapsulated the variables which are only ever going to be changed by a single sprite into "for this sprite only" variables. (This is the same idea as storing data in "state" objects, managed by instances of an object, instead of on variables on the global namespace.)

But let's emphasize one detail - the variable's value can still be gotten by other sprites; it only cannot be changed by other sprites. (This corresponds to "public state" in OOP code.) Here's where the problem comes in: clones, of course, count as "other sprites" (otherwise the point of "for this sprite only" variables in the context of clones would be defeated). This means that, in order for a clone to access a variable of the original sprite, it must use the "(attribute) of (sprite)" block just like any other sprite. The problem is - the original sprite isn't shown in the menu!

I said "distracts" instead of "prevents" intentionally; it is possible to make a "(attribute) of (Sprite A)" block show up in "Sprite A"'s scripts. This is done by dragging out an "of" block into another sprite, then selecting "Sprite A" from it, and then dragging the block back into the original sprite (via the "share the love" feature). But this feels like a bit of a hack; it's picking a menu option you're not supposed to. The trouble is that this is a perfectly good way of using it; it's just that the editor unnecessarily discourages it. Thus, this request is that that should be changed by making the current sprite show up in the "sprite" menu of "(attribute) of (sprite)".

Search the Scratch Blocks code for the "(attribute) of (sprite)" dropdown and inspect how its sprite options are built. Update the menu behavior so the currently selected sprite is included, then verify that the Stage, all sprites, and the current sprite appear as expected.