But that's an entirely different thing than the programs (mkstr and xstr)
being removed. Further I see nothing in mkstr.c which would in any way
"not work", and cross-build support for it should be no different that
for cat or ls (or any other random program) and as we cross-build almost
everything (except perhaps amd64 usually) I very much doubt that either mkstr
or xstr are failing.
That's quite different that using then as tools in a cross-building
environment though, I can't see why mkstr would be a problem even there
though, but xstr might be.
So, no objection at all to SHAREDSTRINGS being removed (which I think has
already happened) - but I still see no rational reason (beyond "I don't see
a need for it") to remove the programs from the system.
I don't share your belief that the src repo benefits from having crufty programs taking up space in it, not to mention the cycles spent building the damn things. We burn enough energy as it is on things without having to keep useless stuff around.
If you want to be able to access the superfluous software, move the superfluity to othersrc or pkgsrc (pkgsrc having the advantage that these programs would then be available to users of other platforms, not just NetBSD). We've done that before with window(1), which I consider a much more useful program than mkstr or xstr - I like it, but still think it was the right decision to move to othersrc.
The danger with using the src repo as a dustbin/trashcan is that the rubbish pollutes the rest (and that src repo has some gems in it that aren't available elsewhere). Plants in a garden don't thrive unless weeding, pruning and active management take place all the time - and the whole garden is all the better for that.
agc