Code change:
I see here that we are intentionally supporting confusing but technically correct syntax. In light of this, we should remove the note here All of these are non-standard things that technically work but nobody actually does in practice. We should either go out of our way to support this sort of thing or not. If we are going out of our way to support this sort of thing, then there really isn't much point of letting the users know that it's unconventional syntax. See also: Personally, I think it's valuable to teach the learners how to write code that others expect to see so that it's easier for them to get hired, but we really need to be consistent. We should either help them with conventions or not bother. If we aren't doing anything after making the note, then it's just visual noise and should be removed.
For what it's worth: This code fails the "bracket notation" test, presumably because of the space. And I'm of the opinion that it should stay that way (I'd be okay with updating the test to allow spacing and adding a third test that clarifies "you should not have spacing"). That being said, there are areas where we are more lenient on the spacing/conventional style, which IMHO is okay if that's not the concept being taught/tested.
For what it's worth here's what I think about formatting. In practice the likes of prettier have rendered manual formatting unnecessary and unhelpful - I don't need to see diff noise obscuring actual code changes. If we're overly picky about formatting then I can see that creating a frustrating experience. However, we should provide nicely formatted code in the examples. That way learners can pick up good habits simply by copying.
I'm generally pretty flexible with formatting. I don't think we have any business requiring a specific brace and indentation style. I'll format utterly unformatted code when someone asks for help and explain how it helps me and the learner discuss the code more easily, but that's a very useful context to discuss readability. But the extra spaces in the above three examples are so unusual and uncommon of syntax that it feels strange to make our tests permit them in the recent couple of issues while also calling it out here as something to not do.
I disagree with both propositions — the note is fine, we should encourage standard style. But also let's not be a PITA. I'll copy my other comment here, so we can have a discussion in a single place:
If we aren't going to enforce/test it, it's just pointless noise that needs to be removed. Text that doesn't related to what is being tested just fills the screen. We have enough trouble getting users to actually read the challenge text without including text we intend for them to ignore.
From an accessibility perspective, I don't think we should be strict on formatting that does not affect the execution of the code. One example that comes to mind is people who are listening to the code. Screen readers don't announce spaces by default so it might not be obvious that there is an extraneous space between the variable name and the bracket notation. I don't think the tests should penalize them for this when the code executes just fine. On a side note, you can use the keyboard shortcut in monaco to format the code and it will remove the space between the variable name and brackets (I just tested it). So I suppose we could require everyone to format their code properly before testing, but this seems like overkill. Or perhaps there is a way to auto-format the code when the user clicks the test button?
I'm not thrilled about intending this syntax to pass, but I find the accessibility concern more compelling than just allowing highly uncommon syntax variations because it can run in other JS environments. But I still say that it we aren't going to test it, then the spacing note should not be there. If its not part of the challenge outcomes, then it's noise. We already struggle to get learners to actually read the parts of the text that relate to their ability to pass the challenge.
Allow me to revise my previous answer just a little. I think I was assuming that this extraneous space issue was being tested in all challenges, but now I'm realizing that it may apply to only this one particular challenge. If so, then as long as the challenge instructions make it clear that this is a requirement to pass the challenge, and there is a clear error message that indicates the reason the test failed is due to the extraneous space, then I think it is OK to leave this test in there if it's deemed important enough to keep. But in general, I do not think such formatting issues should cause a test to fail (as explained above).
Thanks for the thoughts & Here is what we should do: the note. IMHO you all are correct in assuming it does nothing other than draw attention to a confusing notion. should support the technically correct syntax (ignore testing for it, if we are). may be a good idea, but I am afraid of accidentally introducing something else.

Related discussion:
text: The `console.log(array[0])` prints `50`, and `data` has the value `60`. <del> **Note:** There shouldn't be any spaces between the array name and the square brackets, like `array [0]`. Although JavaScript is able to process this correctly, this may confuse other programmers reading your code. </del> # --instructions-- Create a variable called `myData` and set it to equal the first value of `myArray` using bracket notation.