Different getIndicesToRecalculate() codes between 21.3 and 21.6 - clickhouse

Question

recently I'm learning about Clickhouse. While excuting alter table test_minmax materialize index idx, I found that the code goes to MergeTreeDataMergerMutator::getIndicesToRecalculate() func.
Here's some code from branch 21.3
std::set<MergeTreeIndexPtr> MergeTreeDataMergerMutator::getIndicesToRecalculate(
BlockInputStreamPtr & input_stream,
const NamesAndTypesList & updated_columns,
const StorageMetadataPtr & metadata_snapshot,
const Context & context)
{
/// Checks if columns used in skipping indexes modified.
const auto & index_factory = MergeTreeIndexFactory::instance();
std::set<MergeTreeIndexPtr> indices_to_recalc;
ASTPtr indices_recalc_expr_list = std::make_shared<ASTExpressionList>();
for (const auto & col : updated_columns.getNames())
{
const auto & indices = metadata_snapshot->getSecondaryIndices();
for (size_t i = 0; i < indices.size(); ++i)
{
// other code
}
// other code
}
If my skipping index has 35 columns, the loop for (const auto & col : updated_columns.getNames()) will push 35 MergeTreeIndexPtrs to indices_to_recalc even if there's only one skipping index on my table. I wonder if it's a bug, then I found the code remains until 21.6.
Here's some code from 21.6, commit message doesn't tell me the reason.
std::set<MergeTreeIndexPtr> MergeTreeDataMergerMutator::getIndicesToRecalculate(
BlockInputStreamPtr & input_stream,
const NameSet & updated_columns,
const StorageMetadataPtr & metadata_snapshot,
ContextPtr context,
const NameSet & materialized_indices,
const MergeTreeData::DataPartPtr & source_part)
{
/// Checks if columns used in skipping indexes modified.
const auto & index_factory = MergeTreeIndexFactory::instance();
std::set<MergeTreeIndexPtr> indices_to_recalc;
ASTPtr indices_recalc_expr_list = std::make_shared<ASTExpressionList>();
const auto & indices = metadata_snapshot->getSecondaryIndices();
for (size_t i = 0; i < indices.size(); ++i)
{
// other code
}
// other code
}
With code in 21.6, indices_to_recalc has only one element in it as expected.
Why here the loop has been modified? Is code from 21.3 a bug? If not, why there are 35 MergeTreeIndexPtrs of same type in the result set?