Since I finally decided that String::MFN was due an update, I've also
decided to address this issue.
This is not a String::MFN issue. The job of String::MFN is only to
produce strings which are (or resemble) valid and sane Unix filenames.
It normalizes strings within that context, and within that context only.
It does not (and cannot) know how to "normalize" a series of strings
which may represent actual filenames with sequential "parts".
Realizing this, I have removed even the small amount of support that
S::MFN had for trying to recognize track numbers in filenames -- that,
too, is an application domain problem.
Luckily, S::MFN comes bundled with an application, mfn(1p), which will
resolve this request in the near future.
