When I run the project https://snap.berkeley.edu/snap/snap.html#present:Username=s_federici&ProjectName=wrong%20reporter%20x%20position locally, I get "X is not 76" as an output.
I'm using SnaP 5.4.5, Chrome 79.0.3945.130 (Official build) (64 bits), Windows 10
Oh yes, welcome to the joys of floating point arithmetic! 
that depends on the display resolution, the IDE's scale and the stage's scale. Sometimes you get true and sometimes false. This is isn't a bug in Snap! but one we've inherited from JavaScript. Probably best to gently round before comparing...
We should probably detect numbers whose printform has a long string of 0s or of 9s followed by one or two other digits and round them internally. Doing that sort of rounding is Officially Incorrect but nobody's going to run actual moon shots (as opposed to simulated ones) from 
programs.
PS It's not really JS's fault either. It's the fault of the denseness of rational numbers, so any floating point bit pattern represents an infinite range of possible values, even not counting irrational values within that range. I believe that standard algorithms print the median value in that range; instead we should print the simplest (lowest denominator) rational in the range. But I'm not a floating point expert.
Maybe "x/y position" reporters should always output a rounded value? Or would that affect how Snap projects work?
yes, rounding them would make turtle trails veer off pretty fast. Problem isn't the display, but taking the reporter and using it as a value again.
No, the idea isn't to round what the reporter reports. You want to change two things: (1) the conversion to print form, for watchers and speech balloons, and I guess JOIN too, to look for consecutive zeros as I suggested above; (2) the comparison predicates, allowing some fuzz. I think it would be okay to take the two floating point values, zero the rightmost two or (living dangerously) three bits of both, and then do the equality comparison. Well, a little smarter than that so if the three rightmost bits are 111 then you add one to the next higher bit. For less or greater comparisons, first do a rounded equality comparison, and only if that says false, compare the unrounded values to see which is greater.
allowing some fuzz in the equality operation will get us positively flamed by all teachers like Stefano and rightfully so.
Hmm. I think that for most purposes, a modest (two-bit) floating point rounding (as opposed to a fixed fuzz amount) would make kids happier. Not if they're trying to add infinite series or something, maybe.
I've long thought that for text strings the IS IDENTICAL TO block should do case-sensitive comparison, so people can choose which they want, while making the right thing be the thing you get without thinking about it. Maybe we should do something similar for numeric comparison? The = block would round a little, and the IDENTICAL block wouldn't?
I thought at first that this could be misleading, but after a split second I realized that no one is going to compare 76.000000009 and 76.000000123 with "=" to see if they are identical. When you handle numbers like this ones in a computer it is obvious that they are subject to internal approximation, so a perfect comparison is something that I think no one is going to ask for. The usage of IDENTICAL can then be a good compromise if you really are willing to make a perfect comparison.
Stefano seems to be ok with some fuzz, so no one is getting flamed after all.
indeed! I was wrong
How about having both versions (of the ">" and the "<") reporters, as well? The vanilla flavor of the reporters could then do the rounding before comparing the values, while the spicy (i.e. the precision / unrounded) version of the reporters would not do the rounding before comparing them?
Yes, the IDENTICAL version of the "=" reporter would be the spicy one, while the rounding version of it would be the vanilla (version of the) "=" reporter.
P.S.
Maybe somehow similar to the way users can change the flavor of MAP block by right mouse button they could change the reporters' flavor, too?
You can't have an "exactify" option like that unless you invent a visible modification to the block; for example if you click "ringify" the block gets a ring around it!
There are too many cases like this in the language. Consider the trig functions; what if you want radians? The Logo solution is to have RADSIN, RADCOS, RADATAN. But you could imagine a global use-radians flag, or you could imagine a "radians" option like your "exactify" option.
I think we need to think of a beautiful elegant way to handle all such cases. :~)
I think we should not address this at all. If you like you can make your own fuzzy-comparison block.
I agree that a general solution is needed. In the meantime, if I move a sprite to a specific pair of coordinates and then I immediately check if the sprite's coordinates are the ones I moved it to just, the "=" operator MUST be true. Otherwise the language would seem inconsistent. I can accept that the test is false only when I'm moving the sprite by using the MOVE STEPS block and directions other than 0,90,180,270
What do you think?
Sure, I could, but I don't agree. If the script "GO TO 10 10; SAY X POSITION" doesn't give 10 as a result, the user will think that Snap is not working. This is what I thought, even being in CS since 1979.
Then we should provide bitwise operators. Otherwise the comparison has to be very fuzzy.