Peter
Thanks, yep, I admit I have gaps in my Dry System knowledge (I’ve been more heavily invested in Dry Container + Infusible) so sometimes ask strange questions but trying to course correct as fast as possible. 
The initial trigger for going down this path was when I posted this question. I never got a response so figured I was either not asking the right question, no one had an answer, or I was on my own entirely…but Tim has responded. 
Tim
[Providers] can register zero or more components, emphasis on the zero.
Yes, I hadn’t realized the significance of zero until you clarified this. Thanks!
A helpful lens to apply here is: what happens if I only want to partially boot my app.
Yeah, I don’t want to give the false impression that I’m trying to break out of the provider lifecycle. I’m fully on board with leveraging the lifecycle as much as possible. This is a powerful feature. The primary source of my confusion is when I don’t see providers behave as I intuit from reading the documentation and/or source code.
Another way to do certain kinds of configuration could be to use parent classes
Ah, yes, this solidifies and nicely ties together the power of the auto_register: false pragma. Thanks!
given a prepared app only (
Hanami.prepare), when I resolve a single component, can everything be configured sufficiently for that single component to work, and nothing more?
Yep, I’m on board and very much want to stay in this space…but there is often subtle nuance that gets tricky to grok when using Hanami.prepare or Hanami.boot that has been tripping me up.
Tim, to better respond to your comments above, I thought it might be beneficial to include a couple short videos that my illuminate my confusion (which might be of interest to others getting used to Dry System’s provider lifecycle). I’ll work my way through my original examples in the order listed:
Dry Schema/Validation
I only focus on Dry Schema (since the situation is the same for Dry Validation).
I want to emphasize, Tim, that I’m not ignoring your superclass suggestion. I agree, that’s a strong and valid solution but I think it’d be neat to simply prepare Dry Schema/Validation with monad support.
Rack Attack
If you were to attempt to launch the console (which essentially messages Hanami.prepare) the same exception would be thrown.
Sequel
I realize this demonstration is a bit unfair because ROM + Sequel persistence hasn’t been fully sorted out or supported yet. The problem illustrated here is of an order or operations issue and could be partially resolved by ensuring my persistence provider is called first.
I hope the above helps illustrate more of the confusion around the provider lifecyles and why I keep getting tripped up between prepare and boot states, especially when prepare doesn’t exactly behave the way I expect.