Catalog copy/paste FC: Use data owner as prefix in FC alias

Bud

ArcGIS Pro 2.9.5; Oracle 18c 10.7.1 EGDB
and ArcGIS Pro 3.3.5; Oracle 19c 11.3 EGDB

If I create a new FC via the Feature Class Wizard, then the new FC's alias is prefixed with the owner/schema/user name. Result: ENGINEERING.ROADS. That works as expected.

However, if I copy a file geodatabase FC via Catalog and paste it into the enterprise geodatabase, the new FC's alias isn't prefixed with the owner/schema/user name. Result: ROADS. That isn't expected.
As a result, ROADS is displayed as the item name in the Contents pane when the item is added to the map.

I'm wondering if it would be more intuitive/consistent if Pro automatically put the prefix into the alias in the second scenario, just like the first scenario.

SSWoodward

Thanks for the Idea @Bud. This functionality is a feature of the alias property.  Let me share some information that might help provide context here.  You shared that

If I create a new FC via the Feature Class Wizard, then the new FC's alias is prefixed with the owner/schema/user name. Result: ENGINEERING.ROADS. That works as expected.

This doesn't fully capture what's happing.  When you create a new feature class in this manner,  unless you have manually defined an alias on the first tab of the wizard, the new feature class has no alias. When a class has no alias, the software will return the name of the feature class when a feature layer requests it. You'll see the fully qualified name of the feature class used as the name of the feature layer because the class lacks an alias and its the only name we have.

Once an alias has been defined for the class, this property will be maintained through copy. If you copy a class to a new workspace and an alias is maintained during the copy, this tells me it is a user defined alias. That alias should not change. Aliases allow layers created from the class to be represented with a consistent name regardless of the requirements of the workspace or underlying data. 

If you want feature layers to always display the true name of the feature class, then ensuring that the underlying feature classes in your database do not have manually defined aliases is the solution.