ABL2DB futures

I am considering some issues about future directions for ABL2DB and would like to solicit some input from the community.

In ABL, in procedures, we have
(unqualified)
shared
new shared
new global shared

In classes we have
private
protected
public
+ static

In Proparse we have
Imported
Exported

Something is Imported if it is shared, i.e., originally defined elsewhere.
Something is Exported if it is new shared, new global shared, public, or protected, i.e., defined in that compile unit and available elsewhere.
Definitions in procedures with no qualification and private ones in classes are neither imported or exported.

Now, that makes a certain sense, but it means that from the Symbol (e.g., variable name or whatever) I can only tell Imported or Exported, not what qualifier actually made it that way.  To do that I have to parse the actual define node (a bit of a PITA).

In the current ABL2DB schema I have SharedObject, which is all types (TT, WT, variable, query, etc.) and then a table for each type, e.g., SharedVariable.   Anything that is Shared in any way is in SharedObject, so there is no field for shared.  There is a flag in SharedObject for New.  In SharedVariable there is a flag for Global.  It is in SharedVariable and some other SharedX and not in SharedObject because not all SharedObjects can be defined as global.  Each type of SharedX has fields appropriate to that type of object such as DataType or Like.

So, there are two questions here.  One is what I do to support the qualifiers of classes.  I would think nothing in a class is Imported except something defined in a superclass ... and I will have to explore what that looks like ... seems to exist in the Parse tree with no definition or Symbol (???).  So, public and protected are going to be the equivalent of New shared.  So I could:
1. Leave the schema as is and map things like this.
2. Add a flag to distinguish public vs protected.
3. Add a field which recorded the actual qualifier.

The other related question is whether I want to also capture non-shared and private objects.  For things like simple variables, this is certainly less interesting than shared ones, but for things like temp-tables and such it seems possibly more interesting.  And, even for variables I suppose one could do things like report on variables which are not private to a procedure or method, but referenced in the procedure or method ... although there is nothing wrong with that. Buffers, on the other hand, that might be important.   So, choices are:
1. Track only shared things as now, including public and protected.
2. Also track limited other things like buffers (possibly as part of allowing a query to reference more than one buffer)
3. Track anything I can.

Opinions solicited.