I've already started an issues list internally, and filing bugs. But i'm curious to #3 - why would that be important? Is that not used to make sure you've identified the right SQL statement? And then everything you need per the plan/execution is already in the report?
Like, if you asked me to fix your query, or show you where it hurts, I wouldn't really care what the Serial is.
thank you for jumping in!
From the perspective you showed it's correct: If we already identified the query, we don't need to keep this information.
Unfortunately, I'm more often confronted with the generic "please check, it's slow" approach. In this case, I can collect a set of suspicious SQL reports and ask to identify which might be of interest. Such identification can sometimes be done based on Action/Module, or anything the application admin knows how to identify possible SQLs of interest.
Also the SQL Real Time Monitoring Report is not always the last stage of investigation. Sometimes it's useful to dig into ASH/AWR data to get even more details. For such analysis it's very handy to have additional information to identify specific SQL execution of a session.
The last reason I'd like to have such information be visible (and not only in XML) is for documentation purposes. Later on it identifies the specific execution in that session, and not a SQL.
I hope this made it somehow understandable?