Agree with @bmoyles comment re: composition vs. inheritance.  The provisioner needs to have a separation between creating a chrooted volume and what you do that volume.  Let's assume the what you do is called an "Action".  Once the volume is ready, we can start calling Actions and chain them together which can get us around some issues we had for making a base from a foundation in one amination.  Action 1: install chef-solo from script or package URL.  Action 2: install native package that includes cookbooks (or pull from git, tarball, whatever)  Action 3: run chef.  

That would also be very useful for folks that just want to go from foundation to application AMI and don't care about a base.

@bunjiboys approach is starting to appeal to me more as it doesn't touch any existing classes which may make a refactor a bit easier down the road.  It does mean that I'll need to create a fairly identical DebChefProvisioner to his, which duplicates both AptProvisioner and ChefProvisioner.  I think that's the route I'll take in the short term because it's not obvious to me how I can have the ChefProvisioner figure out what platform it's on, load the correct [Apt|Yum]Provisioner configs before the BaseLinuxProvisioner tries to create the chroot.