more examples

proposed/dotnet-sdk-unified-config.md

@@ -64,19 +64,43 @@ My personal suggestion is that we should use [TOML][toml] and advocate for a par
 
 ### Tooling support
 
-CLI commands (dotnet config) a la `git config` will be provided to allow users to set and get configuration values. This will allow users to set configuration values without having to edit the file directly. We should allow reading
+CLI commands (dotnet config) a la `git config` will be provided to allow users to set and get configuration values. This will allow users to set configuration values without having to edit the file directly. We should allow reading of settings keys via a CLI command for easy, consistent access to configuration values.
 
-We should provide a library to parse the file and integrate its data into `Microsoft.Extensions.Configuration` so that tools can easily consume the configuration data.
+`dotnet config get <key> [--local|--global]`
+
+For example, to get the 'realized' value of the `dotnet.telemetry` key for a given repo, you could run the following command in that repo:
+```shell
+> dotnet config get dotnet.telemetry
+true
+```
+and the following command would get the user-global value only
+```shell
+> dotnet config get dotnet.telemetry --global
+false
+```
+
+We (BCL) should provide a library to parse the file and integrate its data into `Microsoft.Extensions.Configuration` so that tools can easily consume the configuration data.
 
 We must ensure that both the CLI and VS support the configuration file and the configuration system.
 
+Inside the `dotnet` CLI (and tools that ship within the CLI), we will initialize a `ConfigurationBuilder` with the `poohbear.config` file and merge it with the user's `poohbear.config` file. We will also seed that builder with environment variables. As a result, every setting will have a matching environment variable _by default_, instead of on an ad-hoc basis. Tools that need the configuration within the `dotnet` CLI will read the appropriate values and apply them to their execution.
+
 ### Secondary goals
 
 Because the configuration file will be read into a Microsoft.Extensions.Configuration context this opens up the possibility for environment variables to be implicitly defined for all configuration keys. This would allow users to set configuration values via environment variables, which is a common pattern and an improvement from the mismatched support for environment variables that we have today.
 
 ### Future work
 
-With adoption, we could soft-deprecate some of the sources of standalone configuration mentioned above. Each configuration file could migrate to one or more namespaced keys in the `poohbear.config` file. For example, .NET SDK tools could live in a `local-tools` namespace that listed the tools and versions.
+With adoption, we could soft-deprecate some of the sources of standalone configuration mentioned above. Each configuration file could migrate to one or more namespaced keys in the `poohbear.config` file. For example, .NET SDK tools could live in a `dotnet.tools.<toolid>` namespace that listed the tools and any tool-specific configuration.
+
+```toml
+[dotnet.tools.dotnet-ef]
+version = "9.0.1"
+
+[dotnet.tools.fsautocomplete]
+version = "0.75.0"
+roll-forward = true
+```
 
 ### Non-goals
 
@@ -106,8 +130,6 @@ The most direct analogue to this is perhaps the [Cargo .config file][cargo-confi
 
 All of these have parallels in the dotnet CLI and tools that ship with the SDK.
 
-
-
 [cargo-config]: https://doc.rust-lang.org/cargo/reference/config.html#configuration-format
 [toml]: https://toml.io
 [toml-spec]: https://toml.io/en/v1.0.0