Epic: Variables pane categories and Package/module/submodule view (handling language-pack differences)

There are a number of open questions around the Variables pane and more generally, how we want to surface to the user the packages/modules they have installed/imported/attached in their environment/namespace.

1. Language-pack specific categories/kinds. Right now, all possible kinds for the variables pane are hard-coded in the Positron front-end, and each language-pack then specifies for any given variable what "kind" it is. This forces a common vocabulary between the language packs, which may be awkward if different languages use different terminology to refer to the same/similar concept (e.g. "Packages" or "Libraries" versus "Modules" although in this case we could potentially use "Packages" for both R and Python) as well as if a certain concept applies only to one language but not another (e.g. "Classes" -- in Python if I import or create a class definition it will appear in the Variables pane, but this doesn't appear to apply to R). Could we consider not hard-coding any category names and letting each language pack provide all relevant categories (and then we'd perhaps just sort the categories alphabetically in the Variables pane)?

• if we decide against that approach, can we alternatively hard-code all possible categories in the front-end, with the idea that perhaps some categories may only be used by certain language packs? This wouldn't require changing any code and is already possible today, but is a shift from our current approach where we've just assumed common categories even though that is not enforced in any way. (for example, PR #2088, Python PR # 320)

2. How do we want to represent packages? We have some current issues around displaying packages in the Variables pane

• https://github.com/posit-dev/positron/issues/1788
• https://github.com/posit-dev/positron/issues/1391
• https://github.com/posit-dev/positron/issues/1369
• https://github.com/posit-dev/positron/issues/1827

But exactly how we do so, across language packs, requires a bit of nuance. For example, are users interested in seeing all installed packages with versions in their current interpreter/runtime (and would this be displayed in a new pane yet to be created)? Or do users just want to see what has been imported/attached? (I think there's probably more value in the former, but there could be a case made that users might be interested in both under different circumstances). If there is value in surfacing what is imported/attached, this works a little differently in R vs Python -- in R a package as a whole is either attached or not, and can be referenced (with explicit namespacing) whether or not it is attached. In Python, a module, or parts of a module, must be imported before being referenced, and a user may import the whole module, specific submodules from the module, or just specific functions/classes/etc from a module. These imports are also commonly aliased in Python (e.g. import pandas as pd; import matplotlib.pyplot as plt). Should these imports and aliases be displayed in the Variables pane, even if all installed modules and version info are displayed elsewhere (e.g. in a new Packages pane?)

3. Similar to the above, how do we handle differences in behavior across language packs, that may require language-specific terminology in the frontend? For example, "Delete all objects" behaves differently in R vs Python. In R, all objects/variables get cleared from the global environment, but any packages that have been attached remain attached -- the only way to reset and remove all packages is to restart the kernel. In Python, however, this button also removes all imports -- any modules, submodules, classes, or functions that were previously imported need to be re-imported in order to be referenced. Do we force all languages to behave in exactly the same way here (which may require digging to find commands that are perfectly comparable in order to implement this behavior in all languages), or is it possible for language packs to also contribute language that provides the tooltip language for the Delete button as well as the language for the confirmation modal that pops up when a user hits the delete button? If the behavior of the languages differ, then the user-facing language should make clear to the user what is about to happen.

There may be some other issues that come up we can link here, but in general, we need to decide on some approaches for handling differences in terminology, philosophy, and behavior between language packs that affect the Variables pane

Start by reviewing the linked issues #1788, #1391, #1369, and #1827, then compare the frontend behavior with PR #2088 and Python PR #320. Define the decisions needed for language-specific categories, package and import display, and Delete behavior; done means an agreed approach for terminology and behavior across language packs.