Under the hood
A scheduled-task lock is now skipped entirely in certain remote sessions instead of being acquired
What
The internal function that acquires a lock before running a scheduled task now returns immediately, without ever touching the lock file, when no explicit lock directory is given and the session is running in a certain remote context. In that situation the lock is simply never acquired.
Why
Skipping the lock check avoids unnecessary file operations in remote sessions where the lock wasn't being used meaningfully, though it means scheduled-task locking behaves differently there than in a normal local session.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
It is unclear exactly what session/context check this guards against or what practical effect skipping the lock has for the reader.