diff --git a/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_14_cb531e5fda28a3114420063106a2131b._comment b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_14_cb531e5fda28a3114420063106a2131b._comment
new file mode 100644
index 0000000000..6f469755c7
--- /dev/null
+++ b/doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_14_cb531e5fda28a3114420063106a2131b._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2021-05-24T20:33:16Z"
+ content="""
+@Ilya, it's different than git-annex unused because that looks at other
+branches and tags. Preferred content only relates to the currently checked
+out branch.
+
+The only preferred contents expressions that this bug affects are include=
+and exclude= ones. For an expression like copies=1, the key's content is
+present or not, no matter how many files in the working tree might use that
+key.
+
+> * a given key is wanted in a repo if the preferred content expression is true for *any* file path which uses the key
+
+Well not exactly, if foo and bar use the same content, and preferred
+content is set to include=foo, and I run `git annex get --auto bar`, it
+will not get the content despite bar's key also being used by foo, which is
+preferred content. I only asked the command to act on bar. That is not
+going to change. When the content is present, `git annex drop --auto bar`
+will, once this is fixed, avoid dropping the content because it knows foo
+also uses it.
+
+I don't think this needs to change user's understanding of how preferred
+content works. It's just git-annex being smart enough to prevent a situation
+where repeated `git annex get --auto; git-annex drop --auto` would continually
+do work, rather than reaching a stable point.
+"""]]