You just might be on to something.
It is quite a challenge to drive 18 LEDs simultaneously at the lowest level (100 lumens ?). That means each LED should output just 5.5 lumens minimum, 666 max. (assuming specified12,000 total).
Straightforward enough for a torch with just a few LEDs and a single driver, but to expect three drivers and banks of LEDs to match closely, in mass-manufacture, is maybe a bit optimistic.
I would prefer to have seen the LEDs arranged so just the inner circle of 6 was used for the lower levels, with the outer ring of two sets switched off. This would require a re-layout of the MCPCB, and a firmware change. It would also allow lower levels down to e.g. 33 lumens.
The cells are 2S as I understand it, and so are the LED's. The stock driver has 3 LED driver circuits, each driving 2S3P LED's, so if it bucks without boosting, you may reach a point well above 3.0V in which it falls out of regulation. Ideally they should have buck/boost to handle both situations.
Even though I wrote Narsil for FET+1 and FET+n+1, I'd much rather have full proper buck and/or boost regulation for efficiency. Driving a FET on PWM's has significant loss's, more were&tear on the LED's for prolonged use anything under 100% of the FET. This is why I really, really like DEL's GT buck driver design - you get all the features of Narsil/NarsilM will full smooth regulation.
The problem with buck/boost is getting high amps from them. Dunno, maybe for a light like this it would be better to run the LED's more in series to raise the required voltage and reduce the amps, then you'd probably need a boost driver though, and not sure what someone like DEL could do for a boost driver design.
The thing is though, potentially we can do this. We could have our own firmware in buck/boost driver designs. Richard has been doing it for a couple years now, though not sure, but think DEL had availability of better performing parts since DEL's design is more recent, plus we have lots of room on SRK size driver PCB's. The parts are more costly of course then what we do with 7135's and FET's though, and more complicated.
I suspect there's somewhat private development efforts goin on, and probably buck/boost related, perhaps with a direct FET channel to achieve high amp output - Best-Of-Both (BOB rule). In the past we used 7135's and FET's for BOB, now look'n at buck/boost and FET.
Well, a 2nd video showed up of a malfunctioning MF01. The power seems to cutoff after being on high for a few seconds and it requires a tail cap twist off, then back on to reset it. This is the video that was posted on Lexels prototype review thread.
But they are the best at 4000 mAh! Seems like these high performance lights need high performance cells, even with all that buck/boost stuff on there - oh well. 
:FACEPALM:
Protection kick in? Meco is definitely not a good match with this light. :FACEPALM:
Able to take the voltage with the batteries loaded in the carrier?
Boy, I recall back in 2011-2012 when just getting started in this hobby, I figured I'd order the best cells around. The most expensive ones are the best, right? So I ordered 4 EagleTac 18650's, protected. Wow, these were the poorest performing protected cells I ever had, even compared to UltraFires and TrustFires. The EagleTac's were wrapped Pana A's, 3100 mAh, which are bad enough, but their added protection circuit has gotta be one of the worse.
I read on Lexel’s thread that each of the three groups of LEDs is 2S3P
Even if there was a dodgy LED in the group, I would still expect the other two parallel pairs in the group to work. So I could understand 2 LEDs being out in the group, but not all 6.
So I still suspect a dodgy driver (doesn’t match the other 2 at lowest level), not the LEDs.
Edit: just saw “He’s using 4x meco protected 18650 (link is external). Facepalm” appeared whilst I was writing. Doh!! So ignore my wild speculation about the latest video (now deleted, strikethrough didn’t work ?).
I still think my theory about the 1/3 group not lighting up at lowest level might have some merit.
Just want to make sure that I do everything right - so you’re saying I should leave the tail cap off, connect the probes of the DMM to the + and - of the inserted battery carrier, switch it to the same setting that I normally use to check the voltage of individual cells, and turn on the light in the highest mode to check the reading?
Without thinking too much about it I thought he was using high drain Olight cells…
definately battery problem
Well, I passed along the information about those cells and it’s probably their protection circuit kicking in to the poster of that video.
If that’s the problem, then it’s not a problem with the light itself. That would be good news.
I really don’t know how this battery performs and don’t plan to buy some to further investigate 
At least one of the problems with his “faulty” flashlight is due to the batteries : “the turbo mode does not work”.
Most likely the cause.
Even assuming brand new protected cells in perfect condition, and all four fitted, with high-current protection circuits, and all four cells load-share evenly, it would be right on the edge. Even if over-current didn’t trip the protection, under-voltage of a high ESR cell drooping under load would take them out.
A true under-voltage would be expected to switch on protection solidly. Requiring a suitable charger to re-set it afterwards.
Bottom line, expecting to get 3000 lumens per 18650 requires top-notch un-protected cells. Worth making clear to prospective purchasers.
Those protected Meca are $3 each and have a 4000 mah rating. Do we need to investigate any further? Lol
[quote=Tom Tom]
They write
They should add, that high-Current Cells are a must, indeed.
That guy from the video can be happy that the protection-circuit works.
Otherwise that could go very very bad…
3$ batteries in such a light… oh me lord
Received mine today.
Holy shit!! This thing blows my Supfire M6-2 away! 
Really one impressive photon bomb.
+1
If batteries have protection try with batteries without protection