The primary concern is that transactions with nLockTime values set in the past or to a lower height are automatically mined and relayed by current protocols. This becomes problematic when considering scenarios where miners may be opposed to certain changes; such opposition could lead to a deliberate effort to censor transactions embodying those changes. This potential for censorship extends beyond miners to users who, for various reasons, might seek to block the relay of specific transactions, such as those with inscriptions they disagree with. The issue at hand is the unintended encouragement of developing more sophisticated tools for censorship within the Bitcoin network.

The conversation also touches on the topic of "readiness" signaling within the context of transaction inclusion in blocks. There's a clarification sought regarding whether "readiness" refers to miners signaling their willingness to include certain transactions or users indicating their acceptance of specific changes through their transaction activities. The point made is that equating the inclusion of a transaction in a block with endorsement is problematic. This is because such an association does not accurately reflect miners' intentions or actions, given that they could manipulate the appearance of readiness by selectively including or excluding transactions. This manipulation undermines the reliability of transaction inclusion as a metric for gauging genuine consensus or acceptance of changes within the Bitcoin community.