Note that a ContainerBuilder will still return the ids of private services (as it contains a definition for it). But this is fine IMO. During the building phase, dealing with private services is expected too.

Good point.. i think its negligible indeed. I hope, with #19683, to deprecate the whole $this->privates thingy anyway.

So, do we consider this a bc break or not?

Im reconsidering this. It makes sense to let getServiceIds return all available service ids (implied by naming), which currently still includes privates by design.

Ie. i think the problem is different, by in general having to deal with privates in a container.

In 4.x when getting privates will throw a exception, they can be excluded from has, getServiceIds, etc. However, to throw, we must still track privates (that is why i like randomizing better, as it completely rules out privates from a container.