docs triage (#25410)

<!--Delete sections as needed -->

## Description

Fixes #25400
Fixes #25399
Fixes #25281
Fixes #25320 and replaces
#25394

## Related issues or tickets

<!-- Related issues, pull requests, or Jira tickets -->

## Reviews

<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->

- [ ] Technical review
- [ ] Editorial review
- [ ] Product review

---------

Signed-off-by: aevesdocker <allie.sadler@docker.com>

Author: aevesdocker

content/manuals/compose/how-tos/environment-variables/envvars-precedence.md

@@ -21,6 +21,15 @@ The order of precedence (highest to lowest) is as follows:
 5. Set in a container image in the [ENV directive](/reference/dockerfile.md#env).
    Having any `ARG` or `ENV` setting in a `Dockerfile` evaluates only if there is no Docker Compose entry for `environment`, `env_file` or `run --env`.
 
+> [!NOTE] 
+> 
+> When `--env-file` is not set, Compose may load up to two `.env` files.
+> It first loads one from the project directory (determined by `--project-directory`
+> if set, otherwise the directory of the first `-f`/`--file` Compose file, otherwise
+> `PWD`). If that file sets `COMPOSE_FILE` to a path in a different directory, Compose
+> loads a second `.env` file from that directory with lower precedence. For more
+> information, see [local `.env` file versus project directory `.env` file](variable-interpolation.md#local-env-file-versus-project-directory-env-file).
+
 ## Simple example
 
 In the following example, a different value for the same environment variable in an `.env` file and with the `environment` attribute in the Compose file:

content/manuals/compose/how-tos/multiple-compose-files/_index.md

@@ -13,7 +13,10 @@ This section contains information on the ways you can work with multiple Compose
 
 Using multiple Compose files lets you customize a Compose application for different environments or workflows. This is useful for large applications that may use dozens of containers, with ownership distributed across multiple teams. For example, if your organization or team uses a monorepo, each team may have their own “local” Compose file to run a subset of the application. They then need to rely on other teams to provide a reference Compose file that defines the expected way to run their own subset. Complexity moves from the code in to the infrastructure and the configuration file.
 
-The quickest way to work with multiple Compose files is to [merge](merge.md) Compose files using the `-f` flag in the command line to list out your desired Compose files. However, [merging rules](merge.md#merging-rules) means this can soon get quite complicated.
+The simplest way to work with multiple Compose files is to [merge](merge.md) them using
+the `-f` flag. This works well for straightforward overrides, but the
+[merging rules](merge.md#merging-rules) can make it complex to manage as your
+configuration grows.
 
 Docker Compose provides two other options to manage this complexity when working with multiple Compose files. Depending on your project's needs, you can: 
 

content/manuals/compose/how-tos/multiple-compose-files/merge.md

@@ -356,8 +356,22 @@ For more information, see [Using Compose in production](../production.md).
 
 ## Limitations
 
-Docker Compose supports relative paths for the many resources to be included in the application model: build context for service images, location of file defining environment variables, path to a local directory used in a bind-mounted volume.
-With such a constraint, code organization in a monorepo can become hard as a natural choice would be to have dedicated folders per team or component, but then the Compose files relative paths become irrelevant. 
+When merging Compose files, all relative paths (for build contexts, environment files,
+bind-mounted volumes, and other resources) are resolved relative to the base Compose file. The
+first file specified with `-f`, or `compose.yaml` in the current directory if `-f` is
+not used. Paths in override files are not resolved relative to the override file's own
+location.
+
+This means that in a monorepo where Compose files are spread across team or component
+subdirectories, relative paths in those files are resolved incorrectly when used as
+override files.
+
+> [!TIP] 
+>
+> If you need each Compose file's paths to resolve relative to its own location,
+> use the [`include` top-level element](include.md) instead of merging with `-f`. Each
+> included file is loaded with its own project directory, so relative paths resolve
+> correctly.
 
 ## Reference information
 

content/manuals/desktop/features/wsl/_index.md

@@ -10,6 +10,7 @@ aliases:
 - /docker-for-windows/wsl/
 - /desktop/windows/wsl/
 - /desktop/wsl/
+- /docker-for-windows/wsl-tech-preview/
 ---
 
 Windows Subsystem for Linux (WSL) 2 is a full Linux kernel built by Microsoft that lets Linux distributions run without managing virtual machines. With Docker Desktop running on WSL 2, users can leverage Linux workspaces and avoid maintaining both Linux and Windows build scripts. In addition, WSL 2 provides improvements to file system sharing, faster cold-start times, and dynamic resource allocation.