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.

-- https://github.com/bitcoin/bitcoin/issues/6100#issuecomment-98471846

like used here. Extensive use of ACK'ing specific commits can be seen here.

The definitions of these terms are all over the place however.

For example, afaict, it's no longer mentioned in doc/developer-notes.md. Seems like the explanation moved to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review which is missing utACK and tACK however but mentions the difference between Concept ACK and Approach ACK.

is there a specific process for aspiring bitcoin core maintainers to become one?

The discussion in the PR about glozow becoming a maintainer gives some insights about the process (or lack of).

[0] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
[1] https://taproot.watch/
[2] https://bitcoincore.org/en/meetings/