Got something like that in practice with backup recovery - IRL most probably the sequence of events leading to that discrepancy was different (not clear yet).

```sql
drop table enum_alter_issue;
create table enum_alter_issue (a Enum8('one' = 1, 'two' = 2)) engine = ReplicatedMergeTree('/clickhouse/tables/enum_alter_issue', 'test') ORDER BY a;

-- backup / move part aside or similar operation 
insert into enum_alter_issue values ('one'), ('two');
alter table enum_alter_issue detach partition id 'all';

-- schema evolution (enum get extended)
alter table enum_alter_issue modify column a Enum8('one' = 1, 'two' = 2, 'three' = 3);
insert into enum_alter_issue values ('one'), ('two');
alter table enum_alter_issue detach partition id 'all';

-- attempt to attach back all the parts (new generation and old generation)
alter table enum_alter_issue attach partition id 'all';

Received exception from server (version 21.9.1):
Code: 53. DB::Exception: Received from localhost:9000. DB::Exception: Type mismatch for column a. Column has type Enum8('one' = 1, 'two' = 2, 'three' = 3), got type Enum8('one' = 1, 'two' = 2). 
```
{
    return !partition_key.column_names.empty();
}
Names StorageInMemoryMetadata::getColumnsRequiredForPartitionKey() const
{
    if (hasPartitionKey())
        return partition_key.expression->getRequiredColumns();
    return {};
}
const KeyDescription & StorageInMemoryMetadata::getSortingKey() const
{
    return sorting_key;
}
bool StorageInMemoryMetadata::isSortingKeyDefined() const
{
    return sorting_key.definition_ast != nullptr;
}
bool StorageInMemoryMetadata::hasSortingKey() const
{
    return !sorting_key.column_names.empty();
}
Names StorageInMemoryMetadata::getColumnsRequiredForSortingKey() const
{
    if (hasSortingKey())
        return sorting_key.expression->getRequiredColumns();
    return {};
}
Names StorageInMemoryMetadata::getSortingKeyColumns() const