While it's true that in general, serialization doesn't necessarily have to concern itself with the types of the objects in question and only record representations of their state... not all serialization implementations do that. Most of the built-in .NET serialization methods do record information about types participating in serialization. There are advantages to that choice (allowing for more robust validation) as well as disadvantages (larger serialized object size), but it's not wrong per se and you just have to live with it.

XNA's content pipeline, for your types, traverses the serializable property (and field) graph and creates readers for them. You can see this behavior if you examine the initialization for ReflectiveReader<T> (the Initialize method, not the constructor). It does this via reflection, not based on the actual data in the XML (again, this is verifiable by looking at the reflected code). So it doesn't matter if there is a reference to the texture in your data or not, if there's a Texture2D property in the type's property graph, it will try to create a reader for it as part of the initialization of the content pipeline.

You are not supposed to use direct references to Texture2D objects in your custom content. You may find this thread (or this one, to a lesser degree). The alleged solution to the issue is to use external references to Texture2DContent instead.

While it's true that in general, serialization doesn't necessarily have to concern itself with the types of the objects in question and only record representations of their state... not all serialization implementations do that. Most of the built-in .NET serialization methods do record information about types participating in serialization. There are advantages to that choice (allowing for more robust validation) as well as disadvantages (larger serialized object size), but it's not wrong per se and you just have to live with it.

XNA's content pipeline, for your types, traverses the serializable property (and field) graph and creates readers for them. You can see this behavior if you examine the initialization for ReflectiveReader<T> (the Initialize method, not the constructor). It does this via reflection, not based on the actual data in the XML (again, this is verifiable by looking at the reflected code). So it doesn't matter if there is a reference to the texture in your data or not, if there's a Texture2D property in the type's property graph, it will try to create a reader for it as part of the initialization of the content pipeline.

You are not supposed to use direct references to Texture2D objects in your custom content. You may find this thread (or this one, to a lesser degree). The alleged solution to the issue is to use external references to Texture2DContent instead.