Oh, and I suggest we call them SESSION variables rather than SCHEMA variables, to reinforce the idea of how long the values in the variables live. A session variable is in a sense a 1x1 temp table, whose definition persists across sessions but whose value does not.
Of course, if they do persist across sessions, then yeah, SCHEMA makes more sense. But every package variable in Oracle PL/SQL was initialized when the package was first loaded into the session.
The key distinction for SCHEMA was that all functions in the schema would be able to see them (and only those in the schema).
I am a bit partial, with little deep thought, to the IMPORT mechanic. Changing them to actual session variables would be doable and you could allow for the IMPORT specification to use search_path or explicit means to locate said variables regardless of which schema
they exist in.
Very important part of my proposal is independence on search_path. With search_path you have not any control over variable type, variable existence - and there are possible lot of impacts on plan cache, behave. So I propose SCHEMA VARIABLES with schema scope - and then search_path has zero effect on the behave. It doesn't introduce new dependencies.
Pavel
However, part of the goal is to blend into the broader database community and thus increase porting capabilities. I'm not sure how well this would help fulfill that goal.