> Но все приведенные выше примеры использования явно этим критериям не удовлетворяют
А вот пример, [удовлетворяющий этим требованиям](https://github.com/dotnet/runtime/issues/34648#issuecomment-627541970). Суть в том, что у класса GC был метод GetGCMemoryInfo, который возвращал структуру GCMemoryInfo с какими-то свойствами, совсем без какой-либо логики внутри. Теперь в .NET 5 хотят добавить новые диагностики о последнем GC. Логично было бы поместить их на этом самом GCMemoryInfo, чтобы не плодить новых API на самом System.GC. Но GCMemoryInfo — структура, добавить ещё 60 байт полей к ней — не самая лучшая идея. Если бы изначальные данные на GCMemoryInfo были полями, то любое решение этой проблемы было бы неприглядным (два API / свойства и поля на одном и том же типе). Тот факт, что это свойства, позволил просто сделать GCMemoryInfo тонкой обёрткой над внутренним классом.
А вот пример, [удовлетворяющий этим требованиям](https://github.com/dotnet/runtime/issues/34648#issuecomment-627541970). Суть в том, что у класса GC был метод GetGCMemoryInfo, который возвращал структуру GCMemoryInfo с какими-то свойствами, совсем без какой-либо логики внутри. Теперь в .NET 5 хотят добавить новые диагностики о последнем GC. Логично было бы поместить их на этом самом GCMemoryInfo, чтобы не плодить новых API на самом System.GC. Но GCMemoryInfo — структура, добавить ещё 60 байт полей к ней — не самая лучшая идея. Если бы изначальные данные на GCMemoryInfo были полями, то любое решение этой проблемы было бы неприглядным (два API / свойства и поля на одном и том же типе). Тот факт, что это свойства, позволил просто сделать GCMemoryInfo тонкой обёрткой над внутренним классом.