I ended up having to create a new device type to handle the information I needed back so that I could ensure the correct values were set on the lock. It was only an extra 4 lines of code added to the default Z-Wave Lock Device Type.
I had originally not wanted to have to edit a device type, because I was hoping to submit my app to ST after I was done with it, but this extra 4 lines of codes in the device type brings my app up from barley working, to working 100% of the time.
My question also became moot when I wanted to extract the list of current values rather than any event that was readily sent by the original device type. The new event sends the object I need with every value, rather than cherry picking for all values.
Still good to know about the filteredEvents attribute. It seems like this still may be convenient for others to be able to use in order to verify that the state is what it should be according to the app, and not the all mighty SmartThings server.