diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment
new file mode 100644
index 0000000000..3bf70bb5fb
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2023-04-25T18:31:20Z"
+ content="""
+Yes -- having some UNIQUEIDs for errors might be quite great!
+
+As for specific field to identify what that error applicable to: the other changed behavior which broke our code/tests was the change to behavior of `annex info` to no longer list unknown to annex path in `\"file\"` and rather list it in `\"input\"` for which the [PR](https://github.com/datalad/datalad/pull/7372/files) was cooked up already.  So may be here it also just should be `\"input\"` field if `annex` desires to not make claims on either it is a `\"file\"` or may be some \"pathspec\" (well -- in DataLad nobody was brave enough to open that -- path-vs-pathspec -- pandora box  [see issues/6933](https://github.com/datalad/datalad/issues/6933))?
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment
new file mode 100644
index 0000000000..d60f16611f
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2023-04-25T18:45:58Z"
+ content="""
+Just for completeness -- do we really need a new type of record for this?  In immediate use case which is [in the heart of the path escaping change discussion](https://git-annex.branchable.com/bugs/started_to_escape_characters_in_the_output/) let's consider other commands.  E.g. `addurl` already reports `--json-errors` just fine in a similar case
+
+```shell
+❯ git annex addurl --json --json-error-messages '\e[31mfo\o\e[0m'
+{\"command\":\"addurl\",\"error-messages\":[\"git-annex: bad url \\e[31mfo\\o\\e[0m\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false}
+addurl: 1 failed
+```
+
+so why just not to make `add`'s 
+
+```shell
+❯ git annex add --json --json-error-messages '\e[31mfo\o\e[0m'
+git-annex: \e[31mfo\o\e[0m not found
+add: 1 failed
+```
+
+into
+
+```shell
+{\"command\":\"add\",\"error-messages\":[\"git-annex: \\e[31mfo\\o\\e[0m not found\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false}
+add: 1 failed
+```
+
+or if you want to expand with unambigous ID:
+
+```
+{\"command\":\"add\",\"error-messages\":[\"git-annex: \\e[31mfo\\o\\e[0m not found\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false, \"errorid\": \"NOT_FOUND\"}
+add: 1 failed
+```
+or alike without requiring some new CLI option?
+"""]]