"2) BMPR physics readiness" - no, it isn’t.
It's one thing to copy the BMPR routine into a table and add an enabling option, which is already way to minimalist for the table to actually benefit from it (or not detriment the table without it on), but to now purport the table as having BMPR physics readiness is going too far, simply false, and / or you truly don't know or care what to do to make it so. For starters, the friction is way too low at .0005 (should be at least .0035), the slope too high at 6 (should be no higher than 5.1 or 5.2), and the rubbers set with incorrect physics settings yielding too little bounce and with no collection groups / dampening routines associated with them (that part on the collections groups for the rubbers, and different groups for different types, is just the tip of the iceberg in what takes more time to do things "right" in a real BMPR implementation). I can also see Aaron's one-size-fits-all flipper settings which vary greatly from the flipper settings I have used for BMPR tables (with or without the flipper dampening routine in play - BSD). In these recent night mod so called "BMPR" tables, you keep copying the dampening routine in, yet in all of them you never call it from any routine or _hit events, be it from a single object or collection of objects, the latter being a key part of getting the objects to start to behave differently.
You just cannot have a "real" BMPR table / implementation without the other physics aspects adjusted and the overall feel blended nor have it be able to be turned off or on with a single option, regardless of whether or not you change the flippers elasticity as a throw-in to your current constBMPR routine processing. I could provide some ideas and assistance on how possibly to make some sort of ”BMPR lite" - a name I would strongly recommend as you move forward in any direction - where a scripted option is still used and some benefits of the routine facilitated with more table parameters being altered as part of the related option routine (.slopemin / .slopemax, etc.). However, you would still need to do more with table objects / auxiliary routine processing and it would be a waste of effort for me to even try if you’re not actually willing to spend some time listening and then, most importantly, doing (both already seemingly in question from my previous efforts and demonstrations, especially with the dozens of hours I spent for Teppo on the Tommy MOD in hopes and as openly discussed in PMs for him to learn by it). If you're just not willing to spend the time to implement it correctly then please stop using it and saying that your tables have "BMPR" because they don't and you're greatly diminishing it's value in releasing it in this fashion (when you just use my base routine and fail to do the other items to match the table with it).
Aaron James, you said you wanted to do the BMPR "justice" in a previous topic, this is the wrong direction and not at all consistent with that sentiment (i.e. turning it into a trivial on / off switch and now claiming the table is BMPR ready).