See my answer here to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.
As for the actual mechanism used to signal, a number have been used in the past:
Early softforks (up to mid 2012) used a simple time based activation mechanism: node software that implements these proposals enforced the new rules on all blocks with a timestamp after a certain date. In the case of BIP16, this date was determined (and modified) in response to miner signalling, but this signalling was just for human interpretation; nodes took no automatic actions in response to it.
Specifically, the signalling used here was to put a string with a support message in the coinbase transaction's scriptSig field, which is otherwise free for miners to put anything in.
Block-version signalling: BIP34, BIP65, BIP66
A later generation of softforks used the block header's nVersion field for signalling (up to the year 2015). Each of those used a subsequent version numbers (BIP34 used version 2; BIP66 used version 3; BIP65 used version 4).
Whenever 750 out blocks number N-1000..N-1 (so 75%) had the proposal's version number or higher, block N would be subject to the proposal's rules. Whenever 950 out of blocks number N-1000..N-1 (so 95%) did, the next block would be required to also signal for it - resulting in a final lock-in.
Versionbits-based signalling: BIP68/112/113, BIP141/143/144, BIP91, BIP341/342
The rollout of relative locktimes (BIP68/112/113) and Segregated Witness (BIP141/143/144) used a different mechanism, which had its own document, BIP9. It specifies using one specific bit of the block header's nVersion field for each proposal, and a finite state machine to determine when to signal and when to activate. Its purpose is/was to permit multiple concurrent proposals to activate, without needing to have one completed before the next one can roll out. This was a downside of the previous mechanism, as it would be impossible to activate the proposal with version 4 without also signalling for activation of the proposal with version 3.
Due to various reasons, segwit was not entirely uncontroversial, and eventual activation happened through a meta-proposal, BIP91. BIP91 itself used BIP9 to activate, which then on its turn made signalling for BIP141/143/144 mandatory, resulting in its activation in August 2017.
BIP341/342 activated in November 2021, using a modified versionbits-based activation mechanism with lower activation threshold, and minimum activation height, in what has been called the "speedy trial" approach.
The future?
Disclaimer: I am a (co-)author of several of the listed documents in this post (BIP9, BIP30, BIP66, BIP141/143/144, BIP340/341/342).
