I think this type of change warrants a larger discussion before a PR. I can think of reasons not to do this.

Thanks for the PR @teruokun, I do think we need to discuss this before preparing to merge. If you have any relevant issues/discussions related to this can you please link to them? Thanks!

I know for my part, I want the ability to test out tool version setups in a subshell and then persist them to a project configuration. Sort of a "lock" approach to the process.

So, the main reasoning is to allow for easy duplication of the asdf current environment used locally on another host. As it may be composed of multiple layers, tracking through all of the named configurations and merging them seems like a lot of repeated logic when what we care about is how asdf specifically will interpret the configuration. This also allows for programmatic reading of the configuration in a more-controlled format as there is no consistent delineation of the standard text output when multiple versions are surfaced (for example, python 3.9.7 3.8.10 3.10.0) to allow for a named default (e.g. python) that can be used side-by-side with version-specific binaries (e.g. python3.10).

So in other words, I want to avoid weird behavior around parsing this output when all I intend for is to use it with another asdf installation

Overall these changes look good to me, and I think this is a nice addition. @jthegedus what do you think?