I think it might be helpful if the name of warn() did not imply that the message is actually a warning, i.e. that "something bad happened". There are many legitimate cases for printing purely informational messages to stderr - operation progress, that sort of thing. When someone sees a hello world app in Zig, and there's warn() in it, the first knee-jerk reaction is, "so what are we warning about?".
I would actually even argue that the meaning of "print" as printing to stdout by default is an unfortunate historical artifact. For the kind of stuff print is usually used by most of the code, it really should go to stderr, and "print" kinda implies some kind of logging IMO.
From that perspective, my suggestion would be to add a no-failure @import("std").debug.print that is an alias for warn. I don't think it's likely that breaking the established convention of print-defaults-to-stdout would cause issues in practice - in programs where this matter (like cat), the developer will quickly discover the issue the moment they try using it in a pipeline. And for programs where it doesn't, defaulting to stderr is actually the right thing.
But if you'd rather not break the convention, how about adding debug.log that is an alias for debug.warn? Or debug.say, or something like it.