It’s the continuing balance between ease-of-use and generality. At a literal level, you can’t use the same tree items in multiple places in the tree, because then various properties would become ambiguous, properties like TVGN_PARENT or TVIS_EXPANDED. (If a tree could be in two places, then it would have two parents, for example.) Of course, this problem could have been solved by separating the item content from the item presence. So instead of just having an HTREEITEM, there would be, say, HTREENODE and HTREENODECONTENTS. The node would represent a physical location in the tree, and the item contents would represent the contents of that node: its name, icon, etc. Sure, that could have been done, but remember the balance. You’re making the common case hard in order to benefit the rare case. Now everybody who is manipulating treeviews has to worry about twice as many objects (what used to be one item is now a node plus contents). This is generally not the balance you want to strike when designing an interface. When you design an interface, you want to make the common case easier than the rare case.

A program that wants this separation can, of course, do the separation manually. Put all the contents in a separate shareable structure and have your HTREEITEMs refer to that shared structure in their lParams. This is more work for the program, but now the cost is being shouldered by the one who wants the extra functionality.