Basically, if an instance of FilterFileSystem uses a different uri (scheme and/or authority) than the embedded fs, the double init made the embedded fs incorrectly report the filtered's uri. This breaks all kinds of things like cached fs instances, dupping of the fs via its uri, fs statistics, setting of the token service which is based on the uri's authority, etc. I think this patch didn't break existing tests because RFS is hardcoded to return file:/// instead of the uri passed to init. This masks the problem that was fixed.
Other FilterFileSystem instances use the ctor that takes the embedded FileSystem, which for the aforementioned reason must not be re-inited, in particular a chrooted fs. LocalFileSystem is unique in that its ctor instantiates a RLFS with no conf and relies on the double init to set the conf in the RLFS. I ran into this jira's issue, so I modified LocalFileSystem instead of FilterFileSystem, to continue to re-init the RLFS because it would be no worse than before.
W/o seeing the source code, ProxyFileSystem appears to be instantiating a RLFS with the default ctor and then "neglects" to call setConf or initialize because it could "get away with it" when it was wrapped in a FilteredFileSystem. As an aside, I think it was a mistake that RawLocalFileSystem exposed the default ctor, instead of forcing the use of the ctor that takes a conf...
Long story (sorry): for backwards-compatibility, I'll see if propagating FilterFileSystem#setConf(conf) to the embedded fs will fix the problem.