You might revise with something like:
Docker containers provide a local .NET Core build environment without additional installation on your machine. This scenario is also useful if your development operating system differs from your build operating system. Application building in a container works well for both client and server applications, unlike most container scenarios.

You might revise with something like:
The goal is to build binaries from your disk source, not to produce a Docker image. After a successful build, the binaries will be on your disk, not in a Docker container.

You might tighten up with something like:
For simple Docker containerized build scenarios, use a combination of docker run and volume mounting, as is done with Develop .NET Core Applications in a Container. For complex Docker containerized build scenarios, first build a custom Dockerfile, or build to an existing Dockerfile stage, as is done with Running .NET Core Unit Tests with Docker.

May want to revise with something like:
Build your application with the .NET Core SDK Docker image. Built assets will be in the out directory.

If this is a requirement, should it be recommended or prescribed? Is the conflict between the folders or the containers?

between container and local.

I think this might be more clear:

To avoid conflicts between container usage and your local environment, you need to use a different set of obj and bin folders for each environment.

Make this change with the following steps:

1. Delete your existing obj and bin folders manually or use dotnet clean.
2. Add a Directory.Build.props file to your project to use a different set of obj and bin folders for your local and container environments.

Application -> Applications
Might consider something like:
Note: Applications built for a different .NET Core version on your machine, or for a specific runtime (-r argument) might not run on your machine.

You might revise with:
Complex application build requirements may need more than dotnet publish provides. A multi-stage build approach can enable a complex build scenario. demonstrated by the following example: The instructions assume that you are in the root of the repository.

Application -> Applications
Might consider something like:
Note: Applications built for a different .NET Core version on your machine, or for a specific runtime (-r argument) might not run on your machine.

You might use something like:
This example assumes an exiting Dockerfile is being used, with a particular stage target.

Tighten with something like:
Run the application on your local machine, assuming you are at the root of the repository:

Should this be Build .NET Core Applications in a Container?

In "Build .NET Core Applications for ARM32 and Raspberry Pi with Docker" under "Building the Sample with Docker" section, this change might help with clarity.

"This sample must be built on a 64-bit operating system, as the .NET Core SDK is not currently supported on ARM32."

Also, line 33: Might consider: "Next, pull the image on an ARM32 device (like a Pi) from the recently pushed registry."

And line 35: You might simplify with " Note: Change the password location and the user account ("rich" and "richlander") example values in your environment. "

Line 46:
First, docker login to Azure Container Registry. For more information, see Push Docker Images to Azure Container Registry.

The current Directory.Build.props is not ideal with the 2.0-sdk image because it doesn't have the DOTNET_RUNNING_IN_CONTAINER variable set. This is going to lead to some confusion.

Now that I merged everything into one doc ... the first two dotnet-watch scenarios require 2.1. The build scenario can work with 2.0 w/o issue. So, we either say it is all 2.1 or back-port env variables to 2.0. I suggest the latter. Thoughts?

I have some concerns about the differentiation between the build and develop samples. I can see this causing some confusion for newcomers. Part of me thinks the two samples could be combined....IDK.

Agreed. Merged.

What is the attraction to running locally? If you depend on a shared framework, then you would need that installed locally. You also note that there are issues with framework dependent deployments as well. Would it be better to show how to include the steps to run the app in a container?

Agreed. Removed.

In "Deploy ASP.NET Core Applications to Azure Container Instances", line 3, - use -> used. ACI is a great option for application testing and can also be used for production deployment (not covered here).

Also, you might remove the second "sample" here on line 3: "These instructions are based on the ASP.NET Core Docker Sample."

Line 19: You might simplify with " Note: Change the password location and the user account ("rich" and "richlander") example values in your environment. "

Might be tighter with something like this on line 29: "First, "admin-enable" your session, an ACR credentials access prerequisite for the subsequent command."

A little tighter with something like this on line 35: "Now login to ACR via the docker cli, an ACR push prerequisite:"

Might be more clear with something like this on line 58: "During deployment, you'll need to enter your password. Type or copy/paste it in. Get your password beforehand from the following command:"

Might be a little tighter with something like this on line 78: "When these containers aren't needed, delete the resource group to reclaim all exercise container resources."