Ohhh - duh me! 
The Attiny841 would be purrfect for this with all it's I/O pins.
Yep, my thinking exactly 
I also have a current control possibility floating around that might be a good compromise but it would most likely need an extra pin or 2 as well. So you can see why the 841 is so amazingly inviting.
Hah, in my previous post I actually wrote out a suggestion for that… then deleted it when I remembered it’d need another connection to the LED to detect voltage. The usual layouts shield the MCU from the LED. 
But yeah, that’s exactly how I measure PWM speeds. Just run an LED in reverse. Ellie-Dee isn’t great at converting photons into electrons, but she’s probably good enough for this purpose.
Yeah, you would need an extra pin which would be seriously hard to come by with the tiny85 but the 841 gives of several to play with, is smaller, more features, newer, offers lower drain in e-switch lights and about the same price too boot!
In narsil triple the LVP from the internal reference works without the resistors
But its not working with a zener or LDO mod for 2S configuration
Adjusting the voltage divider by adding a 2. resistor on top of the existing resistors should be no issue
the Narsil code needs to be altered so the indicator LED pin can be used for the voltage divider, if the LED can be left working that would be great but not the main problem
abnd the internal reference code needs to be deactivated
In narsil 1.2 which is in the OP, the voltage divider is still used. You simply setup the resistors like normal for it. I am using this version on all of my lights because of this.
I have not tried any of the newer versions myself but the internal reference would indeed only work with 1S setups.
If I would be more expirienced with programming I would try to get the bugfixes of Narsil v1.4 into v1.2 and use the voltage divider for 2S builds
Personally the only bug in 1.2 that I have noticed is that if you triple (or is it quad click?) click and get into the blinky modes, it is quite difficult and more a matter of luck to get out of them. I have just learned to not triple click lol.
The LVP change and temp regulation go hand in hand - both driven off the same interrupt. Could be separated of course.
So TA, we need a OSHPark Attiny841 board with wired out pin connections for a dongle to program the thing. Mike C's looks pretty good, but not sure how generic his is.
Arrow has them, Mike used the 4x4 (MU) package - sounds good to stick with it. I see he posted bout custom doing the pads though.
For testing purposes using mikes design is the easiest option I am going to say (if he released the oshpark design that is). I am a bit busy to work on drivers at the moment. Heck I really should not even be posting this post lol.
For the footprint, I did not look at the specs, are there any differences between the 4x4 and 3x3 when it comes to features and programming?
If not then it would simply be on a per-driver basis depending on how much space there is.
Well, he mentioned how tight the pins are on the 3x3, even the 4x4. K, need to find out - think Mike is still in the dev phase on porting the firmware but I'm not familiar with the board. Not that I have for this either - gonna lose my contract here, only/main source of income 
Very nice to see so much going on here, I can hardly keep up with just the reading, let alone the understanding.
Gah! Don’t do that! Anything but that!
It sounds like someone needs to swagger up to Mike and say…
Heeeeey Mike.
That’s a shiny thing you’ve got there.
Wanna give it to me?
*eyebrow waggle*
Mike can do it!
He’s our man!
If Mike can’t do it,
Oshpark can!
Rah rah rah!
Ahhh - you are sooo much better at that than me . I'm ready to hand over anything you want!
Just ordered some ATtiny 841/A samples from Microchip - seems like the order is goin through, but only could get the 14 pin version of the 841, and MU version of the 84A. Well, dunno if I can use them but TK, if you could ask DEL for a nice look'n 841 or 84A OSHPark board design, I wouldn't mind 
As it stands HD's clicky can act like it always does in combination with an eswitch, or if OTSM and ESWITCH are both configured but no OTSM cap is used(just standard C2 cap), it will always produce a long press (which would revert to first mode if memory is off). Or at least I think that's all true. Basically the firmware can tell the difference the between a full a reset and a sleep. If OTSM is used and both switches sleep, then it just tracks which pin was hit anyway, if voltage and e-switch are on different pins at least, but at the moment there's nothing done with that information.
I've included a dual switch build in the last HD posting, but I can't remember how it's setup. I think it's combo eswitch/OTSM, which is should be right for that with memory off and reverse on.
Anyway, you guys have gone mad. I expect TK's next firmware to give me face recognition and open garage doors.
Sorry, I may have had too many of those umbrella drinks.
What do they put in those things, anyway?
Hmm. Those two weren’t on the list, but I did have some other ideas for a future project…
I don’t suppose you have any idea which MCU I’d need for that last one?
So lexel, what do you think, is clicky reset to first or last-used mode good enough, or should I add an explicit clicky reset mode configuration? I wasn't excited about your signaling use case much, but having one siwtch come on in turbo and one come on it moon, actually does sound pretty nice. Just using reverse modes doesn't do that. They'll both default to turbo. I think this could be a nice option.
There are probably too many variations of this to entertain them all. It's possible to have the eswitch do forward modes and clicky do reverse. Or one switch does "hidden modes", Or have two modegroup configurations, one for each switch (actually I really like that). It's possible to have eswitch do crescendo, and clicky step through modes. It's possible to add two more switches and turn into into a nintendo game controller (Then there could be combo moves!). There's really no limit here, but obviously some are simpler than others. Just changing the reset mode of the clicky switch independently of the eswitch is probably very simple.
Of course this dual switch stuff has only had very minimal testing on a bench so far, a few versions ago, so there may be a couple of wrinkles to iron out. Getting OTSM working was higher priority, but it's mostly the same part of the code.