diff --git a/doc/bugs/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment b/doc/bugs/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment
new file mode 100644
index 0000000000..bbd69601be
--- /dev/null
+++ b/doc/bugs/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-02-28T18:47:26Z"
+ content="""
+> AFAIK, there has been no particular change to git-annex that prevents .nfs files from causing problems when git-annex uses posix file locking. There might have been some change in the behavior of a nfs server, eg it might delete the .nfs file eventually, but only after git-annex has tried, and failed, to delete the non-empty key directory. Seems like the kind of thing that network latency etc could make nondeterministic.
+
+Just if that could shine any light, in aforementioned datalad issue, [this specific comment](https://github.com/datalad/datalad/issues/3929#issuecomment-589712933), I state (although show only for the recent annex) that without any change to NFS server/mount, and on a local nfs mount (so network is largely out of question) we ended with .nfs* files with older gitannex and without them in newer.  It might be some change in how git-annex deleted files/directories, but no change to NFS. 
+
+As for the git-annex version differences, inbetween I believe there was this fix [7.20190819-98-g94c75d2bd AKA 7.20190912~21](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=94c75d2bd9a50c6348f716b8b945b056cb56e447) for [regression: fails to detect need for pidlock on an NSF mount](https://git-annex.branchable.com/bugs/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/) which might or not be related -- didn't check
+
+
+> So I'm inclined to merge this bug report with the first of those.
+
+FWIW, that is ok with me.
+"""]]
diff --git a/doc/bugs/git-annex-fsck_reports_dead_keys_as_errors/comment_3_99f2e030519d4fd6351fabb20c0c5f10._comment b/doc/bugs/git-annex-fsck_reports_dead_keys_as_errors/comment_3_99f2e030519d4fd6351fabb20c0c5f10._comment
new file mode 100644
index 0000000000..12d3f64947
--- /dev/null
+++ b/doc/bugs/git-annex-fsck_reports_dead_keys_as_errors/comment_3_99f2e030519d4fd6351fabb20c0c5f10._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="fsck of dead keys"
+ date="2020-02-28T18:44:21Z"
+ content="""
+\"having a file in your working tree whose content is missing is something that it's reasonable for fsck to mention as a problem\" -- makes sense.  For [[`git-annex-fsck --key`|git-annex-fsck]], not sure you need to warn about an explicitly [[`git-annex-dead`|git-annex-dead]]'ed key, but I guess that depends on the context in which the command is used.
+"""]]
diff --git a/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn b/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn
new file mode 100644
index 0000000000..fb98806e58
--- /dev/null
+++ b/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn
@@ -0,0 +1 @@
+Thanks for [[addressing|news/version_8.20200226]] "[[bugs/dotfiles_handled_differently]]".  One small thing: to preserve backwards compatibility, could `--include-dotfiles` be made a no-op, rather than an invalid flag?