Like we did with JFolder we should probably review what other files are missing the jimport for JFile. Would you be intrested in doing that? (You just need to grep for JFile and for the corespnding jimport. Those files in the first but not the second list need to be patched)

Were was this removal documented? Have other applications beside the cms been given timely notice (i.e. minimum one full 3 month tagged release of the platform with deprecation notice in place)?

This was more dependency management cleanup than removing API if I understand right. Basically, classes were loading other classes that they didn't need to, or were modified to not depend on, and other classes depended on those imported classes to already be there instead of handling their dependencies on their own.

Any file/class is responsible for loading all non-autoloadable classes. Just relying on it being loaded by something else is doomed to fail when that something else changes.

Nothing in JFile has been removed, a couple of methods have been deprecated though and so it's used less often now.

This not affect 1.5.X because dont have copy functionality.

So let's get this one merged and make it a huge priority to find places where there is breakage because dependencies were removed without adequate testing/accounting for downstream for breakage. This is why Michael is right about unit tests but nothing with potential dependency in other classes should be removed without fixing all of those at the same time. We can't have a broken trunk.
Can one of you generate a list of all classes where this import was removed and then we can grep for classes where those are called.
But let's not hold up this merge for the sake of that.

Fixed this one in master as well as 2.5.x
Please open a new tracker for similar issues