So here is the modified driver with the suggested changes from @nayelyz :
Click this invitation link → Accept → Enroll → Available Drivers → Install Z-Wave Lock (AR).
Delete the device in the SmartThings app and add it again. Please keep the working device(s) as they are.
This is completely untested, of course. Next week I could add device preferences, so you could configure the behaviour per device.
Andreas;
Thanks so much for new driver. I installed as instructed with no problems and removed and reinstalled locks reporting wrong status. I verified in IDE that your new driver Z-Wave Lock (AR) driver assigned to each.
I was so expecting this to work, however the same result where wrong status reported in ST App after locking and unlocking. I’ve captured the log file of your new driver for the Kitchen entry lock. I took the following actions below:
So no change in behavior which is surprising. The only thing I can think of is doing another factory reset and then adding to smartthings. I wouldn’t think that would change anything. The lock is always added with the wrong status in ST, to that of the physical door. I am a bit perplexed.
I sent log file to build@smartthings.com. If you need me to send elsewhere, please advise. Or if you need anything else let me know.
Kind Regards;
Mark
I could flip the states in other places of the driver, but I don’t think that it solves your problem.
I’ll have a look at it tomorrow.
I think the issue is that these events don’t have a “state_change=true”
But also, something I didn’t consider is that the device also acts backwards when receiving a lock/unlock event, so I think you should define “capability_handlers” to do the opposite on each event because I see that the alarm 24 is now emitting the “unlocked” event as I mentioned before.
For example, the “lock” command was received and translated to “DOOR_LOCK” in the Z-Wave message sent, but it didn’t perform any physical action.
Too much work for two out of three locks that aren’t correctly installed or not compatible with 3-point locks… 
And without device preferences (“inverted lock state”, or something), the now working lock would do the opposite sooner or later anyway.
So, these devices can’t be installed separately? So, only 1 uses the driver from ST and the others the custom one?
Even using preferences, the “capability_handlers” should check “is inverted lock state active?” to see which path to take: the default one or the inverted one.
This is really unfortunate spending $750 for 3 smart locks only to have only 1 reporting correct status. I guess I will just have to live with the confusion in ST app.
I do believe nayelyz is correct in her assessment, because I ran a test on the only lock that works assigning your new Z-Wave Lock (AR) driver to it, where locking and unlocking it via ST app still reports the correct status as what’s physically happening at the door. If your custom driver was working as what we expected, you would have thought that a working lock would end up showing wrong status while the other doors the correct status. Ugh, I just don’t understand how Schlage’s locks don’t figure out their orientation when initially setting them up. Schlage have washed their hands of the issue, not supporting 3-way locking systems w/their smart locks, however none of their documentation notifies potential buyers of this shortcoming. The door manufacturer has nothing to do with it, because they bought linkage hardware to make it work for a 3-point locking system. But this is for all Schlage locks, smart or unsmart and I assume it’s Schlage whom supplies this linkage. But I could be wrong. Thanks to y’all again. Kind Regards; Mark
