DS24B33/DS2431 eeprom

Looks great... and takes care of the page stuff transparently.

I know the usual way is to export only the connect(). The connect hides the new. With 1v72 you could return the OWmem (function) as class (see How to create a module that is a 'Class' - aka a function usable with new - or: How to make require() return a function and not an object).

Exposing the class itself allows to add/modify the prototype by additional, OWmem extending requires and adding method. A similar approach is already used when extending the Graphics class dynamically with specific fonts. For example, require("Font8x16").add(Graphics);, adds the .setFont8x16() method to the Graphics class.

There are other helpful effects coming along: returning the class allows to name it what ever the user wants it to have... to overcome the typical name space issue in JavaScript (taken care of in requre.js/AMD module technique for the browser).

Loading a bare metal OWmem and extending it with what ever space allows and benefits the application the most. I could even see your 'room for improvement' methods using this technique: in bare metal empty defined but already called, and allowed to be overridden on demand. Other methods could be any data conversion types / helper methods to be added
in addition what you already have to make OWmem generically usable.

Dynamic extensions should work with minification. I do though not know about how it works with save().