WCF это не умеет. Это умеет OData, там есть полноценная модель, есть ObservableCollection и INotifyPropertyChanged. То есть полная инфраструктура для подобных задач. Очень удобно. Вот тут подробно про трекинг писал http://codearticles.ru/articles/2519

НемоКэп42А это работает с универсальными приложениями для магазина? Т. е. чтобы и на виндофоне запускались, и на десктопной винде в Modern-интерфейсе.
Кончено. Мы это пользуем в плиточном модерн и в WPF.

НемоКэп42И если что-то своё подобное городить, какую бы схему вы посоветовали? Мне первое, что пришло в голову, это к каждому свойству приписать булевскую переменную, которая говорит, изменилось ли свойство. А для коллекций создавать вспомогательные коллекции, типа RemovedItems, AddedItems, ChangedItems - т. е. фактически создать свой класс, который бы содержал всю эту функциональность по хранению и отслеживанию изменений в коллекции.
Я бы рекомендовал не городить велосипед, а взять готовый функционал. Тем более он не такой тривиальный, как кажется. С OData на клиенте работаешь так же, как с EF, который трачит изменения.

НемоКэп42А мне всё таки про WCF интересно. Если я передаю объект, у которого некоторые поля ссылочных типов равны null - они как сериализуются при передаче? Они много места занимают?
Не заморачивайся мелочами. Либо пустые атрибуты, либо их вообще не будет, в зависимости от wcf привязки и формата.

НемоКэп42т. е. может быть так, что отслеживание изменений будет слишком накладным. Вот я и хотел узнать, что если передача неназначенных свойств и пустых коллекций ненакладна, то мне change tracking всякие не нужны - слишком усложнены они для моей задачи.
Так отслеживание изменений на стороне клиента, а не на стороне сервера. Ты уж определись, нужны ли ObservableCollection и INotifyPropertyChanged у объектов. А то сначала пишешь, что нужно, потом ровно обратное. Определись с архитектурой, а технологию потом подберем.

НемоКэп42А синхронизацию я не хочу вот по какой причине. Я даже на локальной машине сталкивался с проблемой синхронизации при многопотоке. Не успевает UI-часть обновлять интерфейс, как расчётная уже приготовила новые данные. И часто возникает ошибка типа изменённого перечисления, когда расчёт уже поменял какую-нибудь коллекцию, а UI ещё по ней итерирует.
В этом плане нужен полностью асинхронный UI. В XAML отлично разруливается через MVVM + async/await.

НемоКэп42У меня примерно раз в секунду клиент будет отдавать серверу несколько десятков килобайт данных.
Ну это копейки, тут вопрос больше к каналу и его загруженности.

НемоКэп42Так вот, на локальной машине UI не всегда успевал раз в секунду отрисовывать результаты. А клиентские устройства и того тормознее могут быть.
А зачем результаты в UI отрисовывать каждую секунду? Они асинхронно будут отрисовываться по мере ответа сервера.

НемоКэп42, возможно тебе стоить рассмотреть SignalR с push сообщениями.

https://code.msdn.microsoft.com/windowsdesktop/Using-SignalR-in-WinForms-f1ec847b