For them, that's very important, as they use that to supply resilient infrastructure. I hope I'm representing the idea kinda correctly here: They might want to log system events ("SUPERVISOR: INFO system load surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a preamble") on-screen, and critical messages ("gr-digital: FATAL run out of developer coffee") everywhere.
I want that too. I want this to be easily integratable into software that uses GNU Radio as library. And if I'm already making wishes here,
I want loggers that interface to modern logging systems, be it journald, graylog or SNMP. Something.
Speaking as someone who uses GNU Radio as a library, in an application where stderr is definitely not part of the user interface, I'd really like any logging that's done to be able to be directed to the (Python) application for further processing.
I'd further suggest that, when a message identifiably comes from a particular block, it should be redirectable within the scope of any containing top block or hierarchical block. This way, a hierarchical block may have specific handling of messages produced by the primitive or sub-hierarchical blocks it uses — and if the hierarchical block is multiply instantiated, the application can annotate or process the messages in a way specific to the instance.
One possible API for this that comes to mind would be for logging from blocks to be a special sort of message port, which propagates up the hier-block-archy if not otherwise connected.