diff --git a/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn
new file mode 100644
index 0000000000..f1b15b5516
--- /dev/null
+++ b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn
@@ -0,0 +1,81 @@
+### Please describe the problem.
+
+When a Borg special remote becomes inaccessible, git-annex sync interprets it as
+a failed sync. This contrasts from the behavior of git-annex sync when a regular
+git-annex repository is not available, where it'll be skipped instead.
+
+My workflow involves backup drives that aren't always connected, which can make
+this behavior somewhat confusing to see.
+
+### What steps will reproduce the problem?
+
+1. Create a git-annex and BorgBackup repository.
+
+2. Set up borg repository as a special remote.
+
+3. Move borg repository to another location.
+
+4. Attempt to sync, expecting git-annex to skip the borg repository and exit
+   with a success regardless. Instead, git-annex exits with a failure.
+
+See below for a script that produces this error for me.
+
+### What version of git-annex are you using? On what operating system?
+
+Using the Guix package on Fedora.
+
+```
+git-annex version: 10.20230626
+build flags: Assistant Webapp Pairing Inotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.23 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.5 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+#!/usr/bin/env sh
+
+# Initialize git-annex and borg repository
+
+git init repo
+cd repo
+git-annex init 'git-annex repository'
+borg init --encryption=none ../repo.borg
+git-annex initremote borg-repository type=borg borgrepo=../repo.borg
+
+# Sync works as expected when repository is found
+
+echo asdf > testfile
+git-annex assist
+
+# Simulate borg repository becoming inaccessible, which results in a failed sync
+
+mv ../repo.borg ../repo.borg.tmp
+git-annex sync
+"""]]
+
+The following is what `git-annex sync` produces:
+
+```
+git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+commit  
+On branch master
+nothing to commit, working tree clean
+ok
+list borg-repository Repository /home/alvin/Downloads/test/repo.borg does not exist.
+
+git-annex: Unable to list contents of borg-repository: user error (borg ["list","--format","{barchive}{NUL}","../repo.borg"] exited 2)
+failed
+sync: 1 failed
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Been working on an addon command that I'll hopefully get quality enough to be
+worth adding to the related software section soon :)
diff --git a/doc/todo/deleting_a_repository_from_history.mdwn b/doc/todo/deleting_a_repository_from_history.mdwn
new file mode 100644
index 0000000000..c5be914ad7
--- /dev/null
+++ b/doc/todo/deleting_a_repository_from_history.mdwn
@@ -0,0 +1,11 @@
+Say I have two **unrelated** videos repositories. Say that, by some mistake of history, one was added as the git remote of the other. I somehow managed to clean the git history and disentangle the files between the two repos.
+
+Now git-annex still thinks about that other repository. I can mark it as dead, but it will still have location tracking information for all the files of the other repository.
+
+I know about [[git-annex-forget]]: I'm not sure it's what I want. I do not want to "[throw] away historical data about past locations of files", I would actually *want* to keep historical location data for relevant files. I want to forget a *repository* ever existed.
+
+Is that possible?
+
+Marking it with [[git-annex-dead]] doesn't cut it, from what I understand. In [[tips/what_to_do_when_you_lose_a_repository]], joeyh seemed to say "`dead` is the best we can do", as "the automatic merging used on the git-annex branch tends to re-add lines that are deleted in one repo when merging with another that still has them." But now we have something like `forget`, could that be coerced into forgetting just a subset of stuff?
+
+Thanks! -- [[anarcat]]
diff --git a/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment b/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment
new file mode 100644
index 0000000000..1ed45abc29
--- /dev/null
+++ b/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-08-10T01:08:16Z"
+ content="""
+This has happened repeatedly to me and I feel your pain. It is especially likely to happen when using submodules, which can sometimes be uninitialized, so when you enter them and modify `git remote`s from there, you're actually messing up the parent repo.
+
+I'm afraid there's no convenient way to purge git annex remotes except marking as `dead` and then `forget --drop-dead`, which loses past location history as well.
+
+What you can do though is trying to manually kick the bad commit out of the git-annex branch (e.g. `git rebase -i`), then force-push the git-annex branch to all remotes. If you miss one remote, the bad commit will be reintroduced somewhen later.
+"""]]