Alright, until the next demo is ready I shall at least write down a little To-Do kind of list of open topics 
Profile driver
Auto-disconnect on buffer overrun threshold
I've seen that the Bluetooth sub-system keeps all input reports buffered if they're not "consumed" by the profile or function driver which could lead to non-pageable memory exhaustion in case of a bug where the function driver stops consuming and inherently emptying the buffer. I plan on realizing that with a buffer size threshold value of a few kilobytes which, when exceeded, will drop the connection of the controller as there is no "stop sending input reports" command to my knowledge. This protection mechanism should be part of the profile/bus driver as it is the last bastion to system stability 
Same for the control endpoint if the "OK bytes" are forgotten to be consumed. Running out of precious non-pageable memory has to be avoided at all costs 
Harden (dis-)connect state machine
The state machine is almost a 100% finished, I didn't cover a few edge-cases I can't test because I would need to introduce radio connection errors which I can't without the proper equipment, although should implement fallback paths so the driver won't end up in an unknown state and cause hangs or orphaned objects. Again, no open paths allowed in kernel land. They will bite back one day 
Filter driver
This little fella basically works well but needs attention.
Add sideband channel
A filter can't be directly accessed to e.g. send it configuration changes. Therefore a sideband channel or control device object has to be introduced. This is a very good template to base it upon. The control object will be protected by ACLs only allowing administrative users access to protect against abuse. SDDL_DEVOBJ_SYS_ALL_ADM_ALL sounds right for this purpose (context).
Add support for multiple radios
The current assumption is that there's only one radio to work with. In a real world scenario this may be false since multiple "filter-able" Bluetooth host radio devices may be present. Therefore the filter should - in conjunction with the sideband mechanism - keep a reference to every device it's attached to and provide some sort of identification (bus serial, name, etc.). This will also impact the way the filter can be configured.
User-land configuration
It should be convenient for the end-user to enable or disable the drivers patching capabilities during runtime without the need of unloading the filter or having to re-plug or re-enable any devices. Some simple IOCTLs should be introduced for the sideband channel which can then be sent by a simple GUI tool. The driver should then store the state change in the according registry sections it can access (Hardware key sounds like the right place).
User-land tool for control
I plan on providing a simple C#-based tool which displays the available filtered radios with some basic information and some toggle switches to enable or disable PSM patching on the fly and other possible useful information which might come up (host radio MAC address for easy pairing access for example or entirely integrate PS3 pairing).
Setup tools
The recent discoveries of the ViGEm.Setup toolset may certainly benefit this project as well. Maybe portions of BthPS3Util should/could be ported to WiX custom action 
Shibari/Function driver
Not entirely sure if I should continue/publish my Shibari hack which already makes this stack usable. Proper function drivers should be the end goal but those will once again eat quite a bit of time as well. We'll see about that.
So far so good, will ramp up the pace again soon.
Cheers
glad it brings you joy, we're getting very close, just stay with me 
Looks like disabling the patching is working as expected:
Time for a break and go for a little cycling tour 
while the weather is this nice 