It must have been only a warning in 5.02.3, or I could never have compiled it there. (Before 5.02.3 we didn't use the package system like this at all.)
Actually I would like this message to go away altogether in this case, if possible. The actual situation is that GetPut.hs is in fact part of the package "uni-events-test", and the compiler is told to load uni-events-test on the command line. However GetPut.hs is *also* in the current directory during this compilation, so GHC loads it from there instead. I'm not sure what logic would be best here, but my suggestion would be that where a .hi file is found in an import declaration and has an unexpected package name, GHC keeps on searching. If it finds a .hi file with a matching package name, it accepts it, otherwise accept the .hi file with the wrong package name and issue a warning.
If that's too complicated, just ignore .hi files with the wrong package name. But then people might complain . . .
I think this is all way too complicated. GHC's view of modules is fairly simple: they either reside in the home package or another package. If a module occurs in both, then previously it was an error, now it is just a warning. If we were using packages for dynamic libraries, one of the reasons we originally added packages, then it really *would* be an error and you'd be in trouble if you did this! Can't you just fix your build so that the situation doesn't occur? Cheers, Simon