If I read some code like that, I would expect a comment like:

  // silly hack to get the tab control into a good state.
  // it gets confused when ...
  // and this seems to fix it.

Because setting a property can be a function call, it isn’t necessarily a no-op to set a property to itself.

Having said that, the code is still quite bad but maybe it was auto generated by a ui builder or refactoring tool.

Huh? The function is a no-op. The compiler should optimize it into nothingness, but optimization is not the point here. Or was that an attempt at humor?

I don't know how much the C# compiler optimizes code, if it does at all, but I do know that the JIT compiler is smart enough to delete this. So I came up with an awkwardly-worded response that provided information that I knew to be true.

Yes, of course it is trivially optimized out, that's still not the issue. The question is why that function (and several others) exist in the first place! Is there a bug (which is then copypasted several times) and the code is actually supposed to flip between enabled and disabled (in which case it should really be written foo = !foo)? Or something else?

Probably a copy/paste bug that the author overlooked.

Which is precisely my point.

C# has assignment and mentioning overloading by aliasing to getters and setters. The setter may be holding a shared lock and this pattern may make it release.