Is this a new daemon replacing bluetoothd?

Not quite. BlueZ will still be used for BT classic.

Is there any specific reason why BlueZ LE does not attend the needs for Chrome OS? Ive been trying to fix any bugs or features requirements from Chrome OS for a while to avoid this type of split.

We want to move our stack to completely being in userland for many, many reasons. This is not possible with BlueZ. Splitting the stack for the parts we specifically would like in userland seemed the reasonable thing to do.

We have an internal document as to why this.
Sameer, do you think we can share it?

If you could share any document explaining these reasons it would be very helpful.

Btw, doing a split over HCI is not the easiest thing to do, at least not without modifying the kernel parts as well, or perhaps the split is actually on top of the Management socket? Though the later would only really split BlueZ's userland.

Yes  not easy. But, we already have hci split working with only 5 lines of
changes to hci_core.c. And we have two stacks running successfully side by
side already.

c#7: I don't think we can share that doc as-is but lets extract the design & implementation aspects of it plus a bit of the motivation and then we can publish it.

Ok. I'll do that tonight.

Just keep in mind that dual-mode BR/EDR and LE _do_ share states, things like reset affect both of them...

I m aware, yes.