I think you're misunderstanding the purpose of the unique identifier field, and using in ways that will generate undefined results.
When a Query Layer is defined, you are given a great deal of leeway to generate an SQL query. ArcGIS uses that query, with various constraints, to access the data. The most common constraint is a spatial filter clause (using the map canvas boundaries to reduce the feature set for rendering). But the query is also executed when the table associated with a feature class is opened, or when an Identify operation is performed, when a row in the feature table is highlighted, or when a spatial selection is made.
The purpose of the unique identifier is to maintain the linkage between the rows in the table object and the graphics on the map canvas. There is nothing special about the identifier column (which can be of INTEGER, STRING, UUID, or DATE integral types), except that it must be NOT NULL, and that it return a unique value.
ArcGIS enforces the uniqueness, but it can't prevent various forms of unsupported manipulation, like using an arbitrary row number (
rownum) in the unique identifier. The reason this is unsupported is that it violates the purpose of the identifier: If you have spatial query for which rownum 1 meets the selection criteria, then you try to highlight rownum 1 in the business table, they are not likely to be the same row! The same flakiness applies if you
UNION features together and use
MAX() on the rowid column or other sorts of actions which alter the intent to preserve 1:1 relationship between features and rows.
So, the unique identifier should be a genuine property of the row, and is expected to be repeatable in subsequent queries, no matter what
WHERE clause is applied. If you are applying a
DISTINCT operator, it's possible that you are setting yourself up for unexpected behavior (there will also likely be a performance cost). In no case does ArcGIS choose "which rows are dropped from the attribute table" -- this is always in the purview of the database.