Im not really the one to be answering this but I “think” I know about just enough to say I’m pretty mostly somewhat sure that bistro hd can be configured to work with any of the old layouts and with a lot of the old firmware. There are options to select and it spits you out a firmware to your likening. I think 
David_EF the answer yes, bistro-HD will work, BUT it's not clear exactly what you'll gain over BLFA6, that depends.
First a big warning, the BLFA6_EMU-attiny13 build is oversized. It won't work. (I should remove it from compilation. I've been keeping it to see how close it's getting, but I shouldn't ship it compiled by default, oops).
I'm trying to include legacy configurations in bistro-HD, and all configurations shipped are automatically compiled for every chip they are compatible with (a task performed by the included Makefile). I haven't tested any attiny13 build personally though.
There are some advantages and disadvantages to this. The advantage to say biscotti, is it's a single-purpose build tested for that use. The advantage to the HD way is we merge in all the improvements so they get fanned back out to all builds, to the extent each build can take advantage of that. In fact some of the biscotti improvements are in there and some of the other improvements have fed back to biscotti-HD. It's clearly a slightly less stable development model, but provides more features and customizability. At some point for production firmwares focus needs to be placed on testing one configuration well, but I'm testing more and more features (and the TA-OTSM and TA-OTC versions are getting the most testing attention).
At the moment there is a biscotti-HD. That's a single FET though, not FET+1. That build saves space over regular biscotti, allowing to by default include turbo timeout (tap-back-up broken in last release, will be fixed) and it has redundancy checks on the noinit memory to avoid some random failures that might occur with noinit click timing. However, you could instead rebuild it with an extra channel and define a second ramp for the extra channel, removing maybe Turbo timeout to make space.
There is also a "BLFA6_EMU" build. At the moment the attiny13 build is too big, and that's without even including star3 support. Many of the space savings in HD use economy of scale to save space on big builds. Personally I think it's pretty great that this still manages to save space even in biscotti, but pushing to BLFA6 is a maybe a weight class it can't compete in. You could still remove some feature like a strobe and get that to work. But then maybe you just want BLFA6. There's a chance the BLFA6-HD build will eventually fit. It's close, about 30 bytes, but at some point 30 is a bunch and in the end if there's no extra space, it adds nothing compared to the real BLFA6 anyway. The one thing it's probably good for is just if you really like that UI, you can build it on an attiny25.
Oh, in all cases the menu ordering may be different than the originals.
Oh the other thing getting carried back to the 13's is the OTSM_powersave, which saves power even without OTSM to get, probably about 50% longer run-time on moon mode I guess if enabled. That fits in biscotti-HD too, but if I remember right I haven't released that feature on attiny13 yet.
Maybe I’m just behind because I’m so deep into my own drivers, but I don’t know what it is you want. What do you want on the separate channels? 7135s? How many? FET? What toys are you talking about? For example, doesn’t lighted tailcap require an additional resistor? If so, it would be kind of good to know if you want it or not.
For an 11 mm driver, suppose it's possible to do an Attiny85 with bent pins, and bare min extra circuitry we use now (maybe just the 4.7 ohm preceding the diode), but I too am confused about all the new toys thing.
I'm using shaved down 15 mm drivers to run Narsil in some small 16340 and 14500 lights now, but haven't attempted 10 or 11 mm's. Narsil is e-switch only and requires an Attiny85.
I’m sorry I’m having trouble explaining clearly what I want. I just want the benefit of all the newest driver advances being made here at BLF, but I want it all condensed down to the minimum set of components needed to make it work. Does that make it any better?
I’m not looking for a lighted tailcap. When I said “software toys” I meant the new things that mostly Flintrock, TA, and DEL are working on to bring greater stability and efficiency to drivers. Some of it is more hardware related, like the components added by DEL. Then some work has been done to remove the need for some of the legacy components, like the OTSM work by Flintrock to remove the need for OTC. I haven’t kept up with all the changes, though, so I’m not sure which things affect what. I know Tom E worked out using the internal voltage reference in Narsil to remove the need for the legacy R1/R2 voltage divider. I know Narsil is made for E-switch. But is it possible to use that code with a clicky so as to not need the voltage divider? That’s getting into the realm of things that I don’t know because I haven’t kept up.
The reason I want multi-channel is because it’s more efficient. I have a small flashlight with a tiny battery, so I want to get all I can out of it. In this case, that could be just an updated FET+1 design. I just want the most recent set of components to be fit into a ~11mm diameter PCB and be compatible with the latest Bistro and Narsil (and have all the improvements mentioned). But, if I’m going to end up making the driver myself, then if I could just get a schematic with the minimum set of parts needed for the “modern” driver, that would work for me.
Aha, Bistro and Narsil… I’m not at all familiar with them so I don’t know what is compatible with them. I’m not your huckleberry…
David bistro-HD had the R1/R2 divider resistor removal trick before it was even released as bistro-HD (just as a hacked bistro on page 78 or whatever of some thread). That's what "Vcc read" means. It meas it reads the Vcc voltage. People call this the "internal reference" method, but that's a silly description, both the old method and this method compare an external voltage and an internal reference. The only difference really is if the ADC reports x/y or y/x. I'd prefer to call it an inverted read method. Makes more sense, but I'm digressing.
But that was its first feature and that's how the 1-S OTSM firmware is setup by default. However it needs R1/R2 anyway, for OTSM detection. It's also though how the 1-S OTC firmware is setup if I remember right (if not it's just un-commenting a line and recompiling), and that one doesn't need the divider at all actually.
Actually Mike C made an OTSM board and software before I did. What I did was make it fit with a 47uF cap by getting the power requirements down and getting it worked into bistro.
The benefit of 4-channel is to get multi-color. If you want FET+1 or tripple, for more regulated 7135 levels, that's all there. But again, if you want FET+1 on attiny13, unless you want to customize a biscotti-HD build, it's likely that BLFA6 is still your best bet there.
Mike, I’m really impressed with your drivers, especially the latest F-4 driver. But yeah, I am looking for mainstream compatibility at this time. Thanks!
I’m not looking to stick with ATtiny13 particularly. I know the new firmware options require better MCU’s and I’m fine with that. But, to fit into 11mm diameter, it will have to be a small footprint MCU, like the 841 that Mike C is using. I don’t know if the 25, 45 or 85 are available in such small size. I haven’t checked into it. The whole reason for my inquiry here is that I don’t know this stuff, because I have a hard time keeping up with it all. I really want the latest and greatest, but I’m not sure what that is. I just need it to be small enough to fit into 11mm.
I believe the size of the attiny25 (the small version) is the same as the attiny13. Actually, yes I think it's also available in something like a qfn and would work with no software changes. I don't think changing software for the chips will be too terrible though. ATMEL all seems to work very similarly.
You would need to customize a fet+1 firmware though. Either changing ramps and layout selection from the TA configs, or adding modes and features to the BLFA6_EMU config. In either case, it will compile for any of our 4 usual attinys, and on 11mm, I'd consider going OTC and inverted read. You actually could make OTSM work with only R2 though, making R1 just a trace in the board layout, if you're designing your own board. R1 isn't strictly required, and of course you don't need the OTC then, so maybe that works out smaller than an OTC build?
Thanks Flintrock! Now, if I can just figure out what you said… 
Ok, minor update to the TA bistro mode groups. Changed a few more things around slightly after testing out the V1.2 which was better but this should hopefully be the last update. I would love to keep all the mode groups I have gone through but this version of bistro is limited to 23 and they are all full.
In Flints version they should all fit even if they are minor changes. This is a big part of why I am so excitied to see a screen programming come about, it removes all these slightly differnt mode groups and allows everyone to have the exact modes they want.
Oh, I also added a few more HEX versions in this release. It includes a “219C” version of 1.3 which is basically the same firmware except with turbo set to a pwm of 200 instead of 255 (aka, 80% duty). I find this to be about perfect for maximizing the output on a 219C or other low Vf LED without over driving it. It can be used on any LED or light that you want turbo limited to ~80% of max output.
There are also a few “219C” versions of the V1.2 firmware with lower moon modes that I made by request.
All of this is in the same link from the OP.
Haven't looked yet, are the extra modes just commented out? So can I just bring them in and uncomment them or do you have them scattered in different configurations? I've at least figured out to make a regex replace that chops off the extra zeros.
Really we can fit so many modes in HD, even on a 25, that I'm only luke warm about the phone app flashing. It's cool if someone gets it done, but does seem like a heap of work if only for changing modegroups/order. Again, if it can really flash whole firmwares, that would be different, and if TK or someone is going for it anyway, great. It will be nice either way.
Anyway, good timing, getting bistro-HD-1.3 ready and tested.
With HD I'm considering assigning names to every button press, like SW1_SHORT, SW2_MED
and names to actions like HOLD, FORWARD, REVERSE, FIRST_HIDDEN,
So in the config for dual switch lights you could just define your own UI (ok this could be something flashing LED flashing could do with enough space).
I'm having a little trouble how keep it clean, compact (especially without increase size of the smaller simpler builds) and easy for the customizer to understand. Details get it the way. But it's an idea anyway.
I just changed the existing modes in the codes, since I think this will be the final update I didn’t see a reason to leave a bunch of mode groups in there.
Ok, but it seemed from your post like you wanted more modes than you could fit. Do you want to post an HD version with more modes, or it's ok?
Yeah, I have had to change several modes that I would have just left in place and added another mode but due to the limit on modes I just picked the more applicable modes to keep.
You can add them instead of change them to the HD version if you want. I think I changed 3 or 4 groups, mostly I removed the 4 mode and added a 17 mode in a few in order to keep the total modes to 4 with moon enabled, which I find to be the best compromise between options and usability.
More then 4 modes and I noticed people just keep scrolling through them unable to find the high mode as the modes are too close together to really tell which one is which and they loose count. So 4 modes is what I have been focusing on lately.
Plus it makes it easier when all of your lights are on 4 mode groups, you know that the 4th mode is always the brightest (well except for turbo which I like hidden).
I'm glad to see you are considering the TURBO 19 as an official variant. It means I don't have to carry it :). Of course I appreciate the point for low Vf LED's lacking any more dynamic solution at the moment, but I want level 20. Of course I have a fancy build script that builds many varieties of things, but it's actually not that flexible. It varies certain particular configurations according to the file name listed as a the build target, not any configuration. Anyway, there ways to do it, but I have several TA modegroup based builds now, although only 3 I wouldn't call very experimental.
Yeah, I have found that setting the pwm to 200 is the best soultion at the moment to low Vf LED’s and/or hosts that just don’t need all the extra heat of full turbo.
Although I find the simpler way to set it up is to simply change the last FET channel pwm from 255 down to 200 instead of changing the turbo to mode 19. I find it simpler, just change that one number and recompile and it is done.
The best thing with existing hardware would be a voltage compensation arrangement that increased the PWM as voltage dropped. It would also mean you would not need to use thin, long wires and could run normal 20-22awg wires.