diff --git a/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment b/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment
new file mode 100644
index 0000000000..e84e4e6ef5
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Status of the import/export protocol implementation"
+ date="2023-04-07T09:17:21Z"
+ content="""
+As of now, the protocol specification states \"This part is a draft, not implemented yet.\" To which degree is this still true? Would it be possible to implement a custom remote that implements (some of) these features, and have git-annex use it in an importtree=yes,exporttree=yes scenario?
+"""]]
diff --git a/doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn b/doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn
new file mode 100644
index 0000000000..5eb1de0102
--- /dev/null
+++ b/doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn
@@ -0,0 +1,7 @@
+Is it "safe" to run `git-annex addurl` or `git-annex registerurl` in batch mode on a git-annex repository while also occasionally executing `git rm` on that repository while the batch process is running?  By "safe", I mean "the `git rm` process will never crash due to the git lock file already existing."  Is there a way to ensure that a `git rm` invocation will not fail due to locking issues while keeping the batch process running?
+
+The only relevant information I can find on this is <https://git-annex.branchable.com/forum/locks_during_--batch_operations/>, which states that a batch process will not hold a single lock throughout its entire run but says nothing about whether a batch process uses a lock at all.
+
+(I am asking about this because we have a program that runs batch processes concurrently with `git rm` invocations, and very rarely there are crashes due to locking issues with `git rm`.  My boss now wants me to address these issues by shutting down any running batch processes before running `git rm`, but this will be a giant hassle that I wish to avoid if at all possible.)
+
+[[!meta author=jwodder]]