I use it
PS - I have no clue more than you, so charge ahead I guess...
I think you used the right approach to raise this issue.
My personal view is the "correct" solution to this issue is to provide a
type() method for every SDK class, so you can call that instead. Will see
Your workaround looks OK, though you might want to add a test for and call
to the type() method where it is available. This would cut down on the
number of unknown object types you have to report.
I don't think testing for a :type() method and then invoking it solves the problem reliably. Suppose Debug.pp() has a code fragment like this:
if type (x.type) == "function" then
local sdkType = x:type ()
Without any way of knowing that "x" is in fact an SDK object, the method call x:type() could result in an error. For example, "x" could be an object defined by the plugin, with a method :type() that requires arguments. In that case, calling x:type() with no arguments would raise an error. To avoid that possibility, we could wrap the call to :type() with pcall, or we need some other reliable way of determining if an object is an SDK object.
Debug.pp() could require that any objects passed to it don't have a :type() method or, if they do, that it conforms to the SDK semantics, but that makes Debug.pp() less general and more fragile. The debugging environment for the SDK is already very weak and tenuous, so as a principle, it's good to avoid further weakening whenever possible. (It's too bad that Adobe felt compelled to disable most of the Lua debugging primitives.)
Note that once we know that a value "x" is an SDK object, tostring(x) will return it's type (e.g. "LrFolder"), whether it's an old-style SDK object or a new-style SDK object.
Interestingly, this doesn't seem to be a problem with LR4 on OS X. I have a plug that works perfectly well in LR 3.x on both Windows and OS X and in LR 4 on OS X, but which throws this error in LR 4 on Windows.