While working on bug 199136 it turned out that some clients are calling FileUtil.getMimeType(fo, strings) directly and that this method cannot be overriden in FileSystems.
That is unfortunate as it prevents remotefs from optimizing the performance of mime recognition.

[JG01] Do not introduce an overload of a method differing from the original only in the addition of varargs; it is ambiguous in sources. Use String[] withinMIMETypes instead. With only one known caller, convenience is not a concern anyway. (If it is necessary to support varargs for callers, use getMIMEType(String mimeType1, String... otherMimeTypes).)
[JG02] Should there be a AbstractFileSystem.Info2 with String mimeType(String, String[])?

JG01 - with the proposed change, a call fo.getMIMEType() is visually ambiguous between the current zero-arg method, and the equivalent of fo.getMIMEType(new String[0]). It seems the compiler resolves that to the zero-arg method but why risk confusion?

I don't think we risk a confusion, rather opposite, in current state the behavior is natural:
fo.getMIMEType()
finds the best mime type possible while
fo.getMIMEType("text/only")
obviously calls the vararg method and checks for the enumerated mimetypes only (usually). Unless more voices disagree, I'd prefer to keep it as proposed.