I have reluctantly come to the same conclusion as the R6RS editors: that in a Scheme with libraries, scheme-report-environment and null-environment don't make much sense. They are not in IEEE Scheme or R4RS, so there is no formal barrier to removing them.
Semantically, scheme-report-environment holds all the identifiers in R5RS, excepting any which the implementation doesn't provide, like make-rectangular if it does not have complex numbers. Null-environment, on the other hand, contains only the syntax keywords with none of the standard procedures: it is not an empty environment. R6RS preserves these procedures only in the R5RS compatibility library, where they expose only R5RS content.
When adapting the definition to R7RS, I changed scheme-report-environment to contain all the identifiers in all the standard libraries that the implementation provides, and null-environment all the syntax keywords in those libraries. This was the best I thought I could do, but now I think that it provides very little utility.
It's possible to construct any specific environment you want by using the environment procedure, which turns a sequence of import-specs into an environment. In particular, we now have the (scheme r5rs) library, which essentially provides what (scheme-environment-procedure 5) should provide, and there is no portable use of any argument other than 5.