Good questions! I try to regularly review PRs and even have a PR merged into core but I am still mostly oblivious about how bitcoin protocol development and maintenance is organized.
is there a specific framework or decision making system bitcoin core maintainers use to determine whether an update should be merged?
Regarding frameworks, there is USAF which was used for SegWit and "Speedy trial" which was used for Taproot [0,1]. I think controversy in PRs is also considered.
There is also a system of abbreviations:
Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them.
Tested ACK - Reviewed the code changes and have verified the functionality or bug fix.
ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there.
NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.
utACKandtACKhowever but mentions the difference betweenConcept ACKandApproach ACK.