For some reason, emails from liblime.com aren't reaching me promptly
today, so I'll reply to both of the above at once:-

I suspect C4::Normalize would have poor cohesion (probably logical
cohesion) so would prefer creating C4::ISBN and similar, with methods
like new($), raw(), normal(), display() and so on.

Eek. There's already a... plethora of modules in C4::. At the very least, we would be adding C4::ISBN, C4::OCLC and C4::LCCN. If we really need an OOP interface (seems like overkill for the simple reformatting this would be doing), we could have C4/Normalize.pm with subpackages in the file like C4::Normalize::ISBN, C4::Normalize::LCCN, etc.

Supposing that we used a functional layout, we should probably go with a VerbNoun CamelCase function layout, with very similar names for the ISBN, LCCN, etc. reformatting functions. As long as we stuck to it, this would give us some logical cohesion: "I need to format an LCCN for display, and I know that I used isbn_display_form(); I'll just use lccn_display_form()." ISBNSearchForm or even isbn_search_form get my vote; search_isbn is a tad confusing to me at least, since it evokes C4::Search.

Also, as much as I loathe CamelCase, it is the semiofficial koha standard (http://wiki.koha.org/doku.php?id=en:development:codingguidelines).
 
Would the display() methods be best if they use a syspref?

Most likely. Different people might like ISBNs chunked in different ways, or even not at all.

Anyway, if this isn't already in there, maybe we should hesitate on
adding this new feature.  Seems pretty damn compelling to me, though.

I agree; there's a lot of places that need to reformat ISBNs throughout the intranet and OPAC sides.