Tracking: Reflection issues which would be breaking changes if fixed

[GrabYourPitchforks]

Spoke with @steveharter yesterday and realized that there's a category of reflection issues which are truly legitimate bugs but which could be considered breaking changes if they were addressed. This meta-issue is an effort to aggregate these individual issues as we encounter them.

We need to determine the correct course of action for this category of issue. Should we fix them? What's the appropriate balance between allowing 20-year-old code to work without changes vs. forcing all consumers of reflection to read the docs errata?

• Type.IsPublic returns wrong answer for pointer and byref types #12355 - Type.IsPublic returns wrong answer for pointer and byref types
• Inconsistent GetRuntimeProperties() Behavior #28056 - Inconsistent GetRuntimeProperties() Behavior

[GrabYourPitchforks]

I've tentatively marked this 6.0 so that we can make a decision soon as to how we want to address this category of issue.

[krwq]

@GrabYourPitchforks @steveharter have there been any conclusions there? In the meantime I'm moving this to 7.0. For some of these issues like the second one i.e. we could consider adding new overload perhaps (with extra bool telling to show all properties including the hidden ones)

[steveharter]

IMO if a given API is broken (e.g. Type.IsPublic is wrong for by-ref types) we should fix it even though technically it would be breaking change. One consideration on this is whether there is an existing workaround for the incorrect behavior (i.e. check if by-ref type and check for Public some other way) and whether the workaround continue to work as-is even though the underlying issue was fixed -- if so, then IMO it is much more palatable to do these breaking changes.