When adding one thin archive to another, we currently chop off the relative path to the flattened members. For instance, when adding foo/child.a (which contains x.txt) to parent.a, when flattening it we should add it as foo/x.txt (which exists) instead of x.txt (which does not exist).
As a note, this also undoes the IsNew parameter of handling relative paths in r288280. The unit test there still passes.
This was reported as part of testing the kernel build with llvm-ar: https://patchwork.kernel.org/patch/10767545/ (see the second point).
So, M.MemberName is relative to ArcName if it is thin, and it is used as-is if not thin. It doesn't look like we really have to distinguish two here. Could you call computeRelativePath early in llvm-ar and set its result to MemberName? Then I think you can remove special handling of thin archive here.