_xxx_-prefixed functions are supposed to be removed at some point:
As explained in the last call, I would prefer if each _xxx_-prefixed function is introduced in a separate commit, with its associated pull request/bug report. In that way, we can simply revert that commit once the fix is implemented.
For example, the function _xxx_libarchive_mtree_bug() is no longer necessary in -CURRENT, but we still want it to land so we can MFC it into stable/15, after which we can just revert the commit that introduced it.
I would even add some witty comment at the beginning of the file along the lines of: # "Nothing is more permanent than a temporary solution" as encouragement, in lieu of # Functions in this file should be removed before submitting our changes upstream, as that ship has already sailed.

In D58934#1353008, @jlduran wrote:

_xxx_-prefixed functions are supposed to be removed at some point:
As explained in the last call, I would prefer if each _xxx_-prefixed function is introduced in a separate commit, with its associated pull request/bug report. In that way, we can simply revert that commit once the fix is implemented.
For example, the function _xxx_libarchive_mtree_bug() is no longer necessary in -CURRENT, but we still want it to land so we can MFC it into stable/15, after which we can just revert the commit that introduced it.
I would even add some witty comment at the beginning of the file along the lines of: # "Nothing is more permanent than a temporary solution" as encouragement, in lieu of # Functions in this file should be removed before submitting our changes upstream, as that ship has already sailed.

Addressed and commits splitted accordingly

As a side note, remember that the MAINTAINER of NanoBSD is @imp, so he must be tagged as a reviewer. He happens to be auto-subscribed to all revisions, but it is better to explicitly add him as a reviewer, at least for the crucial ones.
Thank you!

In D58934#1354219, @jlduran wrote:

As a side note, remember that the MAINTAINER of NanoBSD is @imp, so he must be tagged as a reviewer. He happens to be auto-subscribed to all revisions, but it is better to explicitly add him as a reviewer, at least for the crucial ones.
Thank you!

ok will do so.

No code changes in this commit. An earlier commit in the stack (D58931) needed a commit-message reword per review feedback, which required a bottom-up arc diff refresh of every commit above it to keep the stack applying cleanly. That refresh is what reset this revision's accepted status, not a content change.

@jlduran, could you re-accept when you get a chance?