This is pure class. So the official best practice for structs in C# if do not make them mutable. The idea of a mutable value type is just nonsense when you think about it.

Here is the best practice advice on structs direct from MS

https://msdn.microsoft.com/en-us/library/ms229031%28v=vs.110%29.aspx

I had been using System.Drawning.Point to hold coordinates in functional/immutable state Roguelike I am working on and realised that against their own advice...... Point is actually a mutable struct.

How could they get this so wrong in the core library :)

Are you using windows GDI for drawing? I wouldn't recommend it =)

Here is the best practice advice on structs direct from MS

No.

The document you are linking to are the framework design guidelines. These are documents that describe guidelines that Microsoft uses when writing the .NET framework libraries and, to some extent, other libraries that must interact with the CLR across potentially many CLR-compatible languages. While many of them are also applicable to your own applications, they should not be considered hard-and-fast rules or generalized "best practices." They must always be taken in context. Even within the framework itself they are just guidelines. They provide initial direction but the implementing engineer is always expected to discard them if there is an acceptable reason within a specific localized context.

Further, System.Drawing.Point predates the existence of those documents as a public resource, and the note on immutability concerns was only added in the framework 4.5 version of the document. They didn't "get it so wrong."

Mutable value types in the CLR do have a place; points and vectors are an excellent example. Specific instances will likely change often and/or be created and destroyed frequently. The latter strongly suggests you may not want to heap-allocate them to help avoid GC churn (especially if you continue to model them as immutable), but the former implies you won't want to introduce the tedium of immutability in the actual process of writing code that manipulates them (which, in this case, isn't going to offer you a whole lot of advantage anyway).