Is testing behavior of many classes in one test still unit testing?
That depends on whose definition of unit test is considered authoritative.
should we change our way of thinking about unit tests and create test cases where there is more than one real object? Would it still be unit testing or is it already integration testing?
When you make backwards incompatible changes, things that depend on what you have changed break. So if your tests are now screaming at you, that's great -- everything is working the way that it is supposed to.
At this point, you've got a couple of choices. One is to rethink the changes you are making to your design, so that they are backwards compatible. This usually means creating new classes and interfaces, and implementing the old use cases in terms of the new elements. In effect, the old code gets refactored to leverage the new way of doing things, where appropriate, and the tests verify that you haven't introduced any new mistakes in doing that. Your new unit tests cover the new behaviors.
Side note: you can at this step deprecate the old way of doing things as a way of managing the change. This allows you to separate in time adding the new from removing the old.
Another possibility is that you decide that this breaking change is necessary, and this is the right time to pay the costs for that. So just remove the problem test. Ta-da! and you are done. Perfectly reasonable choice when you are replacing both the baby and the bath water.
The problem cases lie in the middle; you are committing a "small" incompatible change, and most of the value of the tests is still present, but continue to accrue that value requires a disproportionate amount of work.
Often this means that your tests are spanning to many volatile decisions (see Parnas, 1971) and or that your current design makes swapping elements too expensive.
For example, its easy to pretend that a behavior is a single atomic thing, where in practice it is actually an accumulation of a number of different independent ideas. If you break your tests up so that they are better focused on the behavioral ideas (rather than worrying about structural concerns like "class"), then you tests that are resilient to change outside of their immediate concern.
But let's be honest, getting to that state requires frontloading some thinking and design.
You may want to review James Shore's Testing Without Mocks; or some of the published articles on Property Based Testing, which often take a single behavior and partition it into a number of different tests, which allows you to preserve/re-use many of your tests even when the overall behavior changes.