rosgraph_msgs/Log is a well-defined msg type for logging. However multiple sources discourage downstream packages to depend on it.

• Q-1. What downside can be expected if downstream project uses rosgraph_msgs/Log directly? I think by discouraging such a usage, API is free from guaranteeing stability. What else?
• Q-2. In ROS either somewhere in core package suite or packages commonly used, are there alternative message types (so that downstream can avoid reintenting wheels and maintenance)?

From wiki.ros.org/rosgraph_msgs:

rosgraph_msgs contains message relating to the ROS Computation Graph. Most users are not expected to interact with messages in this package, and it is strongly advised against.

From rep-0100:

The Clock and Log msg files are not considered to be user facing. They are also specific to the ROS middleware implementation and would pollute a more generic ontology like std_msgs.

---

UPDATE: In response to clarification request,

Can you describe what use-case or requirement you're trying to cover/fullfil? It's unclear to me whether you are just looking to show some log messages to your users (in a UI perhaps) or something else.

I'm thinking generic module-to-module API level. So (well-)defined log level, log message (str) are useful. Some more medium to help conveying various other types of log messages is a plus. But yes, end usage of such API I have in mind is making non-engineer facing GUI to present troubleshoot info (to achieve that, our app wants to receive log topic (system-level info) then customize message content to end-user friendly content).