The thing is, I really don't understand what kind of thing you want to do.
Consider a variation of FileSwitchDirectory which someone wants to write. Extensions xyz, abc go do directory 1 and def got do directory 2. That someone will want to reference Lucene extensions in order to achieve that. FSD only takes care of extensions, but someone might need to work on prefixes of files as well.
You can say "that class itself should not care about Lucene's extensions, it should get the extensions/prefixes in a ctor" ...
Well ... let's take FileSwitchDirectory (which is a core Lucene class) and say I want to instantiate it. I need to pass file extensions. How do I pass the .del file as an extension? Do I hard code it to ".del" (or just "del"?) or, or do I put that code in o.a.l.store just for that? Or ... we make IndexFileNames publc and I can happily and safely reference it.
BTW, I'm writing this from a computer w/o the Lucene code – I wonder how FSD is tested, is the test in o.a.l.index because it references IFN or in o.a.l.store because it tests FSD? If it's the former, then I (usually) think it points at a problem in the design.
The @lucene.internal tag gives us exactly that freedom. Instead of me putting code in o.a.l.* (and feel like I'm dong something wrong, and make my code look wrong), I can put it in my package but know I'm risking the chance a certain constant or method impl will change in the future. I've already took that risk when I chose to put my code in o.a.l.* so I prefer to take that risk and not make my code look patchy.
I, personally, don't mind what Lucene's back-compat policy is. Whenever I upgrade my code to a new Lucene version, I re-compile anything. I am happy to get rid of deprecated API, I am happy to take advantage of new, more efficient API, and I wouldn't care if a @lucene.internal class changed, as long as it's documented in the "Changes in back-compat" section in CHANGES, as a FYI - not because it's a change in the policy, so I can read about it quickly (that's the first section I usually check).
That class is just a reference to Lucene's core files. If you want to write that 'Sweep' thing, you might benefit from knowing what is a core Lucene file and delegate the sweep task to a core Lucene instance, while sweeping the rest of the files by another instance (which created them?). If Lucene core will create files w/ other names/extensions, then I believe this class (IFN) should be changed entirely, but I don't think making it public blocks any of these changes, as long as it's tagged by @lucene.internal.