ASP.NET – Microsoft’s Coding Standards for ASP.NET Controls

How should I go about doing this and introducing this standard to my team without causing friction?

You also say:

Two out of my three co-workers have approached me to create a standard coding document that we can use and enforce moving forward

Looks like you already have some buy-in from most of the team. Make creation of the document something that is done by all of you (all four if possible). If this is too time consuming, come up with your document and show it as a draft to your colleagues. Once all of you have agreed and finalized a version you are good to go.

A good place to start is a look at the different stylecop rules - you don't have to adhere to them all, but these will give you an idea of what your document should contain. As an added bonus, you can easily implement stylecop in your solutions and even integrate into an automated build (failing the build if there are violations).

To summarize:

Look at existing tools and standards to decide what you want in yours.

In order to avoid looking like a dictator, make the change a collaborative one.

I agree with Phil Lello that this has probably been over-simplified, possibly to the point that its confusing. A much clearer example of the need and undesirability of (needing to do) defensive copying is the following using C# for concreteness.

class House {
    private Thermostat thermostat;
    private ControlDisplay cc;
    // ...
    public void ShowDisplay() {
        // ...
        cd.SetTemperatureField(thermostat.Temperature.Clone());
        // ...
        cd.UpdateDisplay();
    }
}

Now, if Temperature is mutable, every time we want to show the control display we need to copy the thermostat's temperature even though it is unlikely to be changed by the display. Even if we control the code for ControlDisplay and thus can verify by looking at the source code that it doesn't mutate the passed in Temperature, we still copy because that may be changed in the future. There was no way to communicate and enforce that it shouldn't be changed.

If Temperature were immutable, on the other hand, there would be no need for this copying. The result would be cleaner, more efficient code, that simply makes certain mistakes and couplings impossible.

I imagine most of the instances in the Apple's core libraries are more like the above than like the example provided in the video. I can only imagine a few, somewhat odd, scenarios where code like the original example might conceivably be preferable to code more like your second example (or your alluded to rewriting).