I still kinda think it is, though. Moreso than seeing a key being pressed down. After all, it's on the screen, made of several pixels, overlapping the single-color screen. It (probably) directly represents an object in the game, which although the display of it isn't a part of the games code still is a form of very clear visual feedback.
All of those points are true, but you aren't getting that precise feedback from the game, you are getting that feedback from your computer. And seeing the mouse doesn't even give you precise feedback about the game. Sure you know exactly what you are inputting, but you don't know what that's doing. You don't know that moving your mouse is moving an in-game character around at a 1:1 ratio. You don't know if clicking is doing something in that particular part of the screen. Sure you can infer that info from what the pixel is doing and what the manual told you about the game, but the player inferring what's going on from their limited knowledge is exactly what this jam is all about.
I think you are confusing feedback as a whole and feedback from the game. The feeling of a key being pressed down is a form of feedback telling the player they pressed a key. Seeing the mouse cursor move around the screen is a form of feedback telling the player where they are moving the mouse. Seeing the one pixel turn on or off is a form of feedback telling the player what is happening in the game. The first is feedback from your real life keyboard, the second is feedback from your computer's operating system, the third is feedback from the game. If you start disallowing forms of feedback that aren't from the game then where do you draw the line? What if my game uses the current size of the game window as input, requiring them to resize the window to beat it. Do I need to somehow make them not able to see the window's current size?
Most likely the mouse position will directly correspond to an in-game location, though.
This view you're speaking about kind of opens up weird venues, though. If I write a program separate from the game, and I have it read the game's memory and draw dots over the game window where objects are, would that then be okay since it's not technically part of the game?
I think the mouse pointer deliberation is also affected by the fact that it is on the exact same output device as your bit. Not only that, but also often in a way where it's indistinguishable from the case where your bit area would actually have explicitly and directly output the pointer graphic.
No, I think that that separate program would be cheating as it's taking information from the game, violating the "1 bit of output" rule. However if you made a program that read the bit and converted it from morse code to text that wouldn't violate the rule.
Really the point I'm trying to argue here is that the mouse is not a source of output. What the mouse does affects the game, but what the game does has no bearing on the mouse. Information is only travelling one way: into the game. You keep saying the mouse will correspond to a game location, but I don't see how that matters. The game isn't telling you it treated the mouse position as an in-game location, you only know that because you know how the game works.This doesn't violate any rules of output because this info isn't coming from inside the game.