Oh? Seems like you still want to support old client versions, which means retaining the fragments that they reference. The question then is what implications that has on a server -- do old fragments need to be eventually garbage collected?
This technique of persisting the queries (and fragments) to the server at build time predates Relay - we've been using it on our iOS and Android apps since 2013.
At build time these clients submit their query strings to the server and get a small identifier in return which they can use at runtime to reference the whole query. This definitely means that old queries need to be kept around as long as the clients that use them are still active. Since iOS and Android apps seem to last forever, we're still getting traffic today from just about every version of our native apps we've ever shipped, even from 2012 and 2013. Because of this we decided to not bother with garbage collecting persisted queries, in terms of all the other data Facebook retains, persisted GraphQL queries is a grain of sand in a desert. However, with a bit more work, you could easily keep a hit counter per persisted query and go remove any persisted queries which had no recent hits.
That is fair, I hadn't thought of that. I would argue the difference is perhaps the ease of tracking the different versions and their usage and the ease of collecting versions. Plus the client can fall back to submitting the full query.