Although the devil is of course in the details, how could such an upgrade process look like? and What are the different upgrade mechanism for the major [v1 - v16] and minor [v1.0 - v1.127] version changes?
As Pieter Wuille mentioned in the comments, "There isn't even a proposal. Discussion about activation and all its implications is something to be had after there is a worked-out idea, implementation, and clear buy-in from the community. You could formulate the question generically as "What activation methods are available for future softforks?", but nobody can answer this question for something that doesn't exist"
How is the soft fork signaled?
Initially, soft forks used to be signalled with the block version number, but due to its many limitations BIP-9 (read full documentation here) is used. In BIP-9, the block version number is interpreted as bit field instead of an integer (we currently have 29 bits where we can signal this). BIP-9 also sets a maximum time for signaling and activation. This way miners don’t need to signal forever. If a proposal is not activated within the TIMEOUT period (defined in the proposal), the proposal is considered rejected. The proposal may be resubmitted for signaling with a different bit, renewing the activation period.
How is the consensus change enforced?
BIP-9 counts activation signaling in whole intervals based on the difficulty retarget period of 2016 blocks. For every retarget period, if the sum of blocks signaling for a proposal exceeds 95% (1916 of 2016), the proposal will be activated one retarget period later. Proposals start in the DEFINED state, once their parameters are known (defined) in the bitcoin software. For blocks with Median Time Past (MTP) after the start time, the proposal state transitions to STARTED. If the voting threshold is exceeded within a retarget period and the timeout has not been exceeded, the proposal state transitions to LOCKED_IN. One retarget period later, the proposal becomes ACTIVE. Proposals remain in the ACTIVE state perpetually once they reach that state. If the timeout elapses before the voting threshold has been reached, the proposal state changes to FAILED, indicating a rejected proposal. FAILED proposals remain in that state perpetually. Below is a diagram from Mastering Bitcoin book.
Is the v1 change as "contentious" and time consuming as v0 was?
Again, there isn't even a proper proposal out there.
What are the tasks of node operators and miners?
Miners cast their voting power on the different proposals by mining the block with the particular bit in the block version number. Full nodes, will decide whether they want to treat these blocks as valid or not and whether they should propagate those blocks to the entire network.
