No, shared environments are not included in your load path unless you activate them explicitly. In this sense, they behave the same as regular environments. The only special thing about shared environments is that you can activate them by name instead of path—in every other sense, they work like your regular environments.
The exception is the base environment @v1.x, which is always available unless you take specific steps to remove it from the load path. This is where you can put packages you want to always have available. See Code Loading · The Julia Language.
You can in principle muck around with the load path to achieve arbitrary environment stacks (see the documentation for LOAD_PATH and Base.load_path), but environment stacking is brittle and rarely a good way to organize your workflow. In particular, the loading of dependencies does not respect environment boundaries, so you may end up loading incompatible versions of packages. Imagine you stack NewEnv on top of @scratch and @scratch contains package A which depends on package B version 1, while NewEnv contains package B version 2. Now you can do using A to load A from @scratch, but when the code in A does using B, the version of B that gets loaded is the one in NewEnv, which is incompatible with A. This is one of the reasons it’s a good idea to keep the base environment minimal and only use it for the packages that help you develop and work with your code, rather than the packages your code actually relies on to do its job (for example, create plots).
In short, if you want to use UnicodePlots within NewEnv, then it belongs in NewEnv.