A fairly common pattern I’ve adopted on dimensions where there’s a number/code and a name, both of which are used about equally is to duplicate the member properties so that you get good tooltips in Excel regardless of whether you slice by number or name. So you end up having the same member properties on two attributes.DAXMD preview appears to name the first instance of a member property as TableName[MemberPropertyName] and all subsequent member properties with that name get named TableName[ParentAttribute.MemberPropertyName].I’m worried after I make a change to the dimension (like deleting a member property then recreating it from a different column but with the same name) and redeploy, the naming may change. One option would be to tweak the algorithm used to loop through member properties in DAXMD and give them column names. If the loop ordering rules were clear and straightforward, the cube developer could ensure the column names don't change by, for instance, deleting both member properties with the same name and recreating them in the right order. This might be my preference, but I know the internal ordering algorithms are typically internal behavior customers are told not to rely on.Another option would be to always name member properties TableName[ParentAttribute.MemberPropertyName]. This would solve one problem but create another. The only type of change that would break existing DAX queries is setting AttributeHierarchyEnabled=true on the attribute, which would then change the DAXMD column name to TableName[AttributeName], breaking any DAX queries using that column as a member property. This option would have another benefit... it would help with this issue as it would be more clear which attribute is the parent attribute that needs to be included in the query: https://connect.microsoft.com/SQLServer/feedback/details/775748/daxmd-querying-member-properties-needs-better-error-messageA final option would be solve all problems but introduce a lot of clutter. In MDX, an AttributeHierarchyEnabled=true attribute which is also a member property can be referred to both as a separate attribute and as a member property. You can refer to it with both types of naming. If you presented all attributes both as TableName[AttributeName] and as TableName[ParentAttribute.MemberPropertyName] then you would never accidentally break existing DAX queries. However, this would introduce a lot of clutter. Maybe the redundant TableName[ParentAttribute.MemberPropertyName] column could be a hidden column there only to preserve backwards compatibility for DAX queries?Please do consider these options and consider a change.