So how do I specify in my role processing that should occur when the class is instantiated? Well, I can hack my way around that with attribute builder methods, I suspect.

It is usually best to try and keep the initialization code for a role in the attribute default/builder. This tends to make roles easier to re-use in many different situations and allows the consumer of the role to not have to think about order of initialization and other such uglies. But if you must use BUILD in your role, you can do the following inside your role and it will do what you want.

sub BUILD {} # no-op
after BUILD => sub { ... your role BUILD code here ... }
[download]

As you can probably guess, this will include a BUILD in the class if one doesn't exist and then apply the 'after' modifier. If a BUILD already exists, the class version will win and the 'after' modifier will still be applied from the role. It is a fairly common idiom for when this need arises, but you really should try to avoid this.

But I don't know how to (cleanly) do the same for DEMOLISH.

The same trick applies to DEMOLISH too (although you would likely want to do a 'before' modifier instead of an 'after'). But also the same warning applies as well, you may want to really try and figure out if this is truly a role or would be better served as a class, perhaps using a delegation relationship with the class that is currently consuming your role.

You get the idea: I want the role to quietly do its thing without imposing its will on the class which consumes it.

Generally this is a good approach to roles, which should give you pause whenever you feel the need to inject a BUILD and/or DEMOLISH into the consuming class. BUILD and DEMOLISH are order sensitive things, roles should ideally never be order sensitive.