Yes, it's a good idea to avoid global variables where possible, because of
the capacity for one part of the software to interfere with another
unintentionally.

In this case that's unlikely to be an issue because:
a) If you use the "g" prefix consistently for globals only, then no
programmer on your team should create a local variable with the same name,
so that issue should not arise.
b) The lifetime you need the global to be correct is only the nano-second
between when you assign the value to the string, and when the Report_Open
fires, so the chance of another process interferring with the value in that
timeframe is negligible.
c) If this is a multi-user environment, every user should have their own
copy of the front end, so each has their own variable and will not interfere
with each other's.

I don't think you need use the same approach with OpenReport. The global
string is just a fudge to work around the issue that OutputTo does not have
a WhereCondition. OpenReport does, so I see no reason to use the fudge.

What I personally do is use my own function to call OpenReport. This
function:
a) defaults to preview instead of print;
b) returns True if the report opened;
c) suppresses error 2501;
d) closes the report if it is already open (to avoid the issue where the
filtering is not set if the report is already open.)
e) takes an argument that is a description of the WhereCondition in English
and passes it to the report so that any printout contains a description of
the criteria in a meaningful way.
The description is passed in OpenArgs in A2002 or 2003, or in a public
string in earlier versions.