Formally speaking it's unreasonable to expect that users would have to modify their code unless we also increase the non-minor version. One can discuss that, but meanwhile why not start by suggesting an additional interface, say aggregate_iter? This would allow us to weigh pros and cons and maybe extend the approach...

Having a aggregate_iter would also work, and it would allow for deprecation warnings to be put on current aggregate if it is decided to be removed in the future.

As for how users will have to modify their code if it's replaced, I think the only scenario will be one like this:

fn test() {
    let references_collection: [&usize; 4] = [&0, &0, &0, &0];

    // Works
    slice_of_ref(&references_collection);

    // Does not work, is a IntoIterator<Item = &&usize>
    into_iter_of_ref(&references_collection);
}

fn slice_of_ref(slice: &[&usize]) { }

fn into_iter_of_ref<'a>(slice: impl IntoIterator<Item = &'a usize>) { }

And can be fixed in either of these 2 ways:

// Consume collection, most likely not ideal
 into_iter_of_ref(references_collection);

// Copy to remove one reference
into_iter_of_ref(references_collection.iter().copied());

This could be possibly be remedied using some other generic trait, though I don't know of such way currently, and is most likely is not possible in current rust.

unless we also increase the non-minor version

Since the crate is currently on major version 0 it is allowed to do breaking changes on minor versions:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/#spec-item-4