I don't think this is a bad way to do it at all, as long as you are writing code for "A leaf" - basically, a product that is designed to be the final customization for a customer's site - and no one is going to re-adapt or from what you just built.
I, however, am working on a 'base install' for my enterprise. I have ten, no wait, 15 different departments that all want one-off's from the base. By saying all of these subsites would never want a required audio field would guarantee that one of them will want it - under a certain folder only - based on Murphy's law.
I really don't want separate content products for each install.
But I guess we've already gone down that road, because some subsites have different "analytics requirements" which conditionally show fields. In my ATContentTypes install, I implemented this as an add on with schemaextender, then added "toggle the fields on and off" with add-on configuration. So I'm already using a registry.xml / add-on config approach.
Applying a conditional behavior (a condiditional, condittional adapter?) based on both the content type and browser layer would be a sweet option for me. I haven't tried adding a layer attribute to a plone:behavior zcml element yet. I bet it won't work. At best, it will generate an xml validation error. Most likely, it will simply be quietly ignored.
This is one case where I think a model driven (xml) behavior would work better, because then we can use GS profiles to play with the knobs and switches, and that fits in nicely with the current model.
So, today (I will change my mind tomorrow):
I think behaviors should optionally be implemented with xml models - like dexterity types - and we can do this with GS profiles.
I also think behaviors can become layer aware. Not sure how hard that's going to be, or how much coupling that creates. I'm skeptical.