CDK-320 is has been recently stalled because it requires accessor-like exposure of a FileSystemDatasetRepository constructor. The use case, however, is more like an SPI package because we want to extend the FS support in kite-data-hcatalog. In addition, the filesystem package has features in CDK-376 that need to be exposed through an SPI package also, so they can be used to support the CLI (and examples).
I went to create a org.kitesdk.data.filesystem.spi package, but the only public member of the existing filesystem package is FileSystem.Builder, which could also be moved into an SPI. I think the correct way forward is to place the entire filesystem package under the SPI and make a reasonable part of it public so implementations (such as Hive) can be built on it.