Noticed with copies of the TextMeshPro/Distance Field shaders.
 
Original post: [https://unity.slack.com/archives/C06TQ82JY/p1680093001453539]
 
The case this was seen in:

1. At boot an instance of the shader and default property sheet get created.
2. The color properties are defaulted to low-range and all have {{m_Flags}} values of 0, so "_FaceColor" (the problem property) ends up with its {{m_Descs}} flag with {{kMaskSRGB}} set.
3. An instance of this shader (and a material) is now loaded from an asset bundle. {{m_Flags}} in this case is set to 16 ({{{}kPropFlagHDR{}}}), as the _FaceColor value is high-range. {{m_Descs}} does not end up with {{kMaskSRGB}} set.
4. A script 'corrects' the shader of the material to what is the embedded version of the shader. From the script's perspective this doesn't seem it should be an issue since they share the same properties anyway.
5. The shader set calls {{BuildProperties}} which does a\{{ ShaderPropertySheet::CopyFrom}} using the 'default' copy of the shader's property sheet, including the\{{ m_Descs}} state which means {{kMaskSRGB}} ends up set, as if the properties aren't going to now have the serialized values dropped in.
6. {{AssignDefinedPropertiesTo}} copies in the high-range colour values which are not recognized as high-range because of {{{}m_Descs{}}}'s state having been changed, so the values get incorrectly converted.

The precursor to this happening appears to be having the in-project version of the shader somehow serialized with m_Flags values serialized as 0 for the HDR properties.