The compatibility constraints of even your internal bookkeeping
The Listview control when placed in report mode has a child header control which it uses to display column header titles. This header control is the property of the listview, but the listview is kind enough to let you retrieve the handle to that header control.
And some programs abuse that kindness.
It so happens that the original listview control did not use the lParam of the header control item for anything. So some programs said, “Well, if you’re not using it, then I will!” and stashed their own private data into it.
Then a later version of the listview decided, “Gosh, there’s some data I need to keep track of for each header item. Fortunately, since this is my header control, I can stash my data in the lParam of the header item.”
And then the application compatibility team takes those two ingredients (the program that stuffs data into the header control and the listview that does the same) to their laboratory, mixes them, and an explosion occurs.
After some forensic analysis, the listview development team figures out what happened and curses that they have to work around yet another program that grovels into internal data structures. The auxiliary data is now stored in some other less convenient place so those programs can continue to run without crashing.
The moral of the story: Even if you change something that nobody should be relying on, there’s a decent chance that somebody is relying on it.
(I’m sure there will be the usual chorus of people who will say, “You should’ve just broken them.” What if I told you that one of the programs that does this is a widly-used system administration tool? Eh, that probably wouldn’t change your mind.)