is there any difference between 
and 
? i never noticed any but ive been wondering about this forever. rn im working with clones and want to make sure im not using the wrong blocks.
No, they're the same. Object's menu input lists all the sprites, so "myself" is an obvious shorthand, especially if this code will be run by more than one object. On the other hand, one's self is clearly a property of an object, same as parent or children (clones).
that what i figured, but so dont they use different methods to access the object? and if so wouldnt that make one block more appropriate depending on the circumstance? i know im splitting hairs here, but im genuinely curious
I think you're overthinking it. Those two blocks weren't designed together. MY in particular wasn't designed at all; Jens just throws things in as he needs them. Any option of MY that's of type Object (as opposed to type List-of-objects) could be in OBJECT also, e.g., OBJECT [MY PARENT]. If this had all been designed, I wouldn't have let Jens get away with MY [STAGE], which isn't an attribute of the sprite at all. (Although I suppose it could be, if someday we have multiple stages, with each sprite living on one of them.)
... and you're not thinking it through, Brian 
this option refers to the stage by role, not by its name. We need (and use) that role to make libraries that work in projects whose stage has been given a different name by the user or has been translated to another language. Geez, folks!! If you made more projects yourself you'd notice such things instead of constantly musing about design principles in the abstract.
no, like Brian's 
Oh, you mean if you change the name, OBJECT [STAGE] changes to OBJECT [FOO] but MY [STAGE] doesn't change? Huh, you learn something every day.
But if you switch from English to some other language, do they both change?
The point is that sometimes you need to write a block that works with THE STAGE, regardless what its name might be, because you want to share that block in a library. That's when you need to refer to the stage by its role, which is the point of MY STAGE.
(In retrospect I regret our decision to let users name the stage themselves, If I did it again I'd stay with Scratch's decision not to)
it translates it : 
=> 
doesnt change, even if you rename the stage, you have to go back and reselect the new name from the dropdown for it to point to the stage again
Yeah I get that, but I'm asking about details. OBJECT [STAGE] changes when you change the name of the stage? Because you could imagine that OBJECT [STAGE] could work like OBJECT [MYSELF], which doesn't change if you change the sprite's name.
i think
: / 
::
:
its confusing because they have the same name as what they are (their role?). its like naming a person 'Person'. if they went to a different country, the word person would change but the their name, 'Person', would stay the same.
Yeah I get that. I don't need an explanation of the deep ideas; I need to know what the actual behavior is!
Which I've just checked. When you change languages, both OBJECT [STAGE] and MY [STAGE] change to the new language. Same for OBJECT [MYSELF] and MY [SELF]. (Sidenote: In the French translation both MYSELF and SELF change to MOI-MÊME. Google says that SELF in French is SOI.)
When you change the name of the stage, you get OBJECT [FRED] but MY [STAGE] (or the translation of STAGE to the chosen language). When you change the name of a sprite, you still get MY [SELF], but for OBJECT you get this:
or in English:
I.e., you still have MYSELF above the line, and also the sprite's name below the line.
What does that line mean? In practice I guess it means that below the line comes the list of all named sprites (that is, not including temporary clones), by name, and above the line everything else. I can see how this makes sense as an implementation, supposing there's already code in the implementation to produce a list of sprite names.
But as a user, it seems strange to me. In the case of my self, it appears in the menu twice: once, above the line, by role (MYSELF), and once, below the line, as named object (MARSHA). Why isn't it the same for the stage? Above the line it should be called STAGE, translatable, and below the line it should be listed by name, not translatable.
I don't think this is a disaster or needs to be changed quickly or anything. But I present it as evidence for my claim that these blocks are not designed; they just grew.
(Another piece of evidence is the lack of visible organization of the MY block's menu. At the very least it needs dividers; even better would be submenus so that the categories could be called out by name rather than implicit.)
thats just the way i understood it. i was referring to the behavior, i was just using a metaphor.
and oh my 
you said i was overthinking it, no need to add stage twice (or else why not add every object twice?), take myself out, and the my block would have those word-by-definition references; my [ self ], my [ stage ], and object would have those by-name references; object [ Fred ], object [ Marsha ]. i agree the my block is a bit messy though. some dividers would be nice.
Because most of them don't have special roles in the object system. I could imagine having "Parent" above the line too. But I guess you're right, if we're going to have my [stage] perhaps we could live without object [stage]. But then the block should be called OBJECT NAMED or something.
so is there a difference between a sprite - stage relationship and a sprite - sprite relationship? like does a sprite 'know' about the roles or does it just see another object?
So I'm guessing your kinda left-field question comes from the fact that you like to read the Snap! source files, and so you see this.parentThatIsA(Stage) all over the place (where this is a sprite). I have no idea why it's ilke that. I mean, the proximate reason is that that's how John did it implementing Scratch, but to me it feels like a messy confusion between the ideas of part-of and one-of. E.g., radio buttons are part of a radio, but they don't inherit from radios, because it wouldn't make sense to apply the same methods to both. (There are methods shared by sprites and the stage, but only because both of those are legit children of Morph.)
I suppose maybe for Real OOP People there's no such thing as a global procedure; everything has to be a method of something. And so the Scratch/Snap! global blocks have to belong to some object under the hood, and so John and therefore Jens put them in the stage.
But none of that has anything to do with the picture we give to users, namely, sprites and the stage are two entirely different kinds of things. You can't clone the stage. So your question really doesn't arise.
OMG, I so hate these half-informed ill educated musings about what y'all are reading into the source code. In Morphic "parent" means container, nothing more, nothing less. And "parentThatIsA()" includes the receiver in case it qualifies the given type, which is why the stage also returns itself if being sent that message, a concept otherwise known as polymorphism.
In JavaScript, "prototype" is the gimmick that governs inheritance.
If you want to learn JavaScript, please learn JavaScript, and if you wish to learn Snap, DO NOT READ THE SOURCE CODE, because you also don't read Python's C source code to understand Python. I can't believe I have to say this over and over again. If you're interested in Morphic, please do read the source code and do with it whatever you want, but for heaven's sake stop conflating the two.
Can we please, please, pretty please stop these amateurish-but-pro-sounding source code discussions in this forum? No wonder kids are all getting the impression that there is some deeper truth reserved to the initiated that read the sources. Why-oh-why are we inflicting these pedagogical horrors on this community?
omg this is ridiculous. youd think having two of the developers here id be in pretty good hands but you two bicker like a married couple. i cant believe im getting third wheeled in this, my own post. i mean its becoming a pattern, i ask a simple question about snap, bh "answers", jens gives a nice and thorough explanation why bh is wrong. you both are being drama queens and this thread is a disaster.