In other words, you want to provide something along the lines of DBI's catalog methods. So, what I would do is the following:

• Define a mechanism for creating objects without having to know the whole class name. Something like DBI's connect where the DBD is figured out from the DSN. I would suggest using various items:
  • Manufacturer
  • Model
  • IP address / Windows address
  Remember - you still have to talk to this printer, so you need to be able to specify that it is this printer that that object is representing. Also, are there ways to auto-detect what manufacturer/model a given printer is if you know the IP address?
• Define the interface by which you interrogate the object. Instead of using your attrs() method, I would actually have the Printer::Status::Acme::x1000 class provide methods. So, that way, you can say something like

  if ($printer->can( 'serial_number' ))
  {
      print "Serial Number: ", $printer->serial_number, $/;
  }
  [download]

• Provide a set of guidelines for authors, similar to the DBD-author guide that tbunce created. You also will want a mailing list. Then, when someone wants to write one of these, they will come to the mailing list and be educated in the ways of the architecture. That's how you make sure you don't have serial_no() vs. serial_number() vs. ser_no().
• If there are multiple ways to access the information, the PSD (printer-status definition) author should be able to support them, but provide a useful default. Then, the user can specify in the connect() clause which connection method.

You really need to study how DBI did things. I'd also suggest using the namespaces PSI (printer-status interface), PSD (printer-status definition), and PSIx (other printer-status modules).