I don't understand what you mean by that. The status shows you what is in the property selected. If you select msg.fred and status then it shows msg.fred as the status. Perhaps I am missing something.
Even though you have deselected debug window, the setting for msg.something determines what is shown in the status. If you remove that then you won't (by default) know what is shown in the status. You might just as well say that when debug window is selected and not status then the default name should be debug not msg.payload. The default name tells you what is displayed, the setting for debug window and/or status tells you where it is displayed.
But I've never changed from using msg.payload to msg.something so its not something that's occurred to me
(to be completely honest - I did want to get status of msg.something once and I just added a change node to swap from msg.something to msg.payload before the debug node - I hadn't really noticed that I could change it in the debug node itself)
I'd suggest changing it to (status) msg.payload (or something like that) but I know compatibility is No 1 with any pull request and therefore we wouldn't want to mess up visual look of existing flows by having the debug node getting longer
I wonder if its possible to do a slight color change instead?
Yes, but not sure about s being the symbol .... I'd prefer a symbol that indicated something but didn't need possible translation, maybe or ↲ ? or.... plenty to choose from
Also we don't really want multiple suffix if both to log and to status are selected... in which case imho I'd prefer external to have priority.
ok ... cut and paste is your friend...
not insisting on ↲ - just a possible suggestion (to try to indicate the info is appearing just below)... but hey
My reason for wanting a change is so we can easily tell the difference between a debug node that is sending its output to the debug sidebar for analysis and other reasons and one that is just being used as a quick visual indicator of what's happening on the flow in real-time.
In (mine at least) normal developement practice I litter debug nodes all over the place but then disable most/all of the ones sending to the debug side bar and just leave the status ones enabled
To do this, I change the name on the status only ones to "status" (or s if being lazy) but then things go a bit awry if i subsequently make it send it to debug and I end up with a node saying status but its not
My original request at the start of this thread was to default the displayed name to status if only status was selected and the name was blank.
@Colin had perfectly valid objection so I'm wondering if it might be a compromise to prefix the label with "status:" (or "s:" or "so:" etc)
I'm aware that adding "status:" status would increase the node length (compared to s: or adding the suffix) so it would effect the visual look of existing flows
I think the part that I struggle with here is the idea of adding any annotation to the label of a node to tell you it's using node status when the node status itself appears a few pixels below.
I do note that a newly deployed Debug node set to log to node.status does not display any status indicator until a message arrives. Would it help if such a Debug node sent a blank status message on deploy to ensure the status indicator was visible?
This issue is telling whether the node is JUST doing node status - as you say - its obvious that it is displaying status info - I just want to easily tell without having to edit node, whether its not sending to debug as well.
Not for me - but its given me the idea of changing colour of the icon?
I'm using a simple Blocky node followed by a normal Debug node
So I can just switch the Debug node on/off but still see status
But it takes it more real estate - the Blockly node has to be recreated/copied on each new Node-RED instance and it can't be switched off without re-deploying (and more processing overhead of course)
or ↲ ? or.... plenty to choose from 
