More clarity in Documentation on Hierarchy specific TI Functions that aren't Hierarchy specific

In the TM1 Reference Guide (which is still called that even though it is in the Planning Analytics Knowledge Centre) ...

The TI Function HierarchyElementSecurityPut takes a HierName parameter, however, it actually updates the }ElementSecurity_ cube, ie the Dimension level cube, rather than any new cube that has an additional Hierarchy dimension or an }ElementSecurity_: cube.

Similarly ElementAttrPutN/S take a HierName parameter. However, it actually updates the }ElementAttributes_ cube.

So in both cases the fact that the TI Function has a HierName parameter implies that it is possible to vary security or attributes by Hierarchy within a dimension but in practice this is not possible because the values are stored at the Dimension rather than the Dimension:Hierarchy level.

Ideally these functions should not have been created if they don't actually work. However, if this HierName parameter has actually been added for possible future use, then the Documentation should make it clear that the function is not currently Hierarchy Specific and the HierName parameter has no effect.

Personally, as far as Security goes, TM1 Security is already complex enough, and I don't see an immedaite need for it to be made Hierarchy Specific. I cannot see why I would ever want to give someone WRITE access to an Element in one Hierarchy and READ in another.

There is perhaps a greater case for Attributes, in particular Aliases being Hierarchy Specific. However, a simple work around for that would be to just create a different Alias for the Hierarchy, populate it appropriately and to then set that Alias in the Default Subset on the Hierarchy.

I have checked that the HierarchySubset functions are actually Hierarchy Specific.

Given this, is there really a need for the Hierarchy specific functions for Security and Attributes, which don't actually work.

Interested in Comments from other users as to whether they see a need for Security and/or Attributes to be Hierarchy Specific, and if so, why? 

Hierarchies are relatively new. IBM probably need to put more thought into what should and should not be hierarchy specific before creating functions that don't actually work as described.