diff --git a/doc/todo/lockContent_for_special_remotes.mdwn b/doc/todo/lockContent_for_special_remotes.mdwn
index c5929404b5..6103c0925c 100644
--- a/doc/todo/lockContent_for_special_remotes.mdwn
+++ b/doc/todo/lockContent_for_special_remotes.mdwn
@@ -20,6 +20,24 @@ remotes, without needing to set mincopies to 0 and risk losing content.
   b) wait long enough or document well enough to be sure that situation
   never happens.
 
+  > Maybe this second part is not a problem actually? Analysis follows:
+  > 
+  > There are 2 git-annex
+  > instances A and B, and 2 special remotes X and Y. A is using the old
+  > program that does not support locking, B uses the new program that does.
+  > Both X and Y have a copy of an object.
+  > 
+  > If A is dropping from X, it will not trust Y to satisfy mincopies,
+  > since A cannot lockContent Y. So it will not drop from X.
+  > 
+  > If B is dropping from Y, it can lockContent X, and so the drop
+  > succeeds.
+  > 
+  > It seems it's ok for B to trust lockContent X, even though A does
+  > not check if X is locked when dropping from it. Because A will not
+  > drop from X unless it's able to satisfy mincopies by locking the
+  > content somewhere else. --[[Joey]]
+
 * directory could use fcntl locking
 
   This would need a transition, because dropping from directory first needs
@@ -29,6 +47,8 @@ remotes, without needing to set mincopies to 0 and risk losing content.
   the first change, then wait several months or years before making the
   second change.
 
+  > Update: See analysis above, should also apply here.
+
   Also, the directory might be on a filesystem that does not support
   locking, with various failure modes. And unlike a git-annex repo,
   there's nowhere in a directory special remote to record information about
diff --git a/doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment b/doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment
new file mode 100644
index 0000000000..ad65c144e2
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-04-12T16:30:06Z"
+ content="""
+Both of these ideas above seem to suffer from race conditions,
+which lockContent needs to prevent. lockContent needs the remote to
+support an actual exclusive locking operation.
+
+Do you have an external special remote that could actually support that?
+"""]]