I think this is a good suggestion.
Please correct me if my assumptions are wrong, but if I understood the general gist of it correctly
then the main point here is that, rather than focusing on specific names, such as
ObjectSpace.trace_object_allocations_start or ObjectSpace.this_aptly_named_method_is_really_not_easy_to_remember,
the main idea is that you can, sort of "activate" a more general debug-centric way to handle
output that may be relevant for getting additional information about different
objects. In the specific example, you tie it to Kernel#p such as the:
p obj
example shows. So basically, the idea is to get more information that is useful for
debugging, without depending on specific API names as such, yes?
In that case I think it's a good idea.
To your three questions, I'll only comment on the Kernel#p last part.
I think it is fine to modify Kernel#p in this case. You could perhaps add
ObjectSpace.enable_tracing, ObjectSpace.strop_tracing or just a flipper
ObjectSpace.flip or ObjectSpace.trace for simpler names. Good API design
is hard. What I like about the idea is that you can sort of get more
information with simple things such as p (or perhaps pp ... could pp
also be used here? tenderlove once wrote that he is a puts debugger,
on his blog; I am a pp debugger! pp all the things).