This has come up a couple of times in the past, and I've been in contact with a couple of the texlive maintainers over the question whether texlive has freedom issues or not. Unfortunately, as is often the case with these things, no clear conclusion could be reached.

This is less prevalent in texlive-bin, but more so in texlive-core, where we drop a metric bunch of of things from the package, making our distribution of texlive a bit whacky.

The rebranding we do in texlive-bin is nice to have, but may be not strictly required. on the other hand, the diff to the arch package is a bit larger than just the distribution title, so there's more things to be evaluated there to reach a conclusion.

All of this reminds me that our texlive is currently a bit out of date. more work to do..

your assessment is correct, I think. However, addressing your point 5 requires us to also do points 1, 2, 3 and 6. 4 needs investigation. I think these lines originate from the arm upstream pkgbuild.

Oh, point 4is not a real difference at all:
While Arch has

--enable-xindy --disable-xindy-rules --disable-xindy-docs

   local config_extra=()
   case "$CARCH" in
     x86_64|i686) config_extra+=(--enable-xindy) ;;
     armv7h) config_extra+=(--disable-xindy --disable-cxx-runtime-hack) ;;
   esac

....

     --disable-xindy-rules --disable-xindy-docs \
     ${config_extra}

so point 4 is just another part of point 3 (remove xindy for arm).

To summarize, only point 5 is freedom issue, the others are direct consequences of adopting the PKGBUILD.

Wait. This would lead us to the discussion, whether the change of the banner requires/justifies modifying the PKGBUILD.
Especially just figuring out what the actual changes are took me some (unnecessary) time. (well, now it is documented ;-))

$ grep texlive-bin /usr/share/doc/your-freedom/blacklist.txt
texlive-bin:texlive-bin:parabola:2695:[branding] [semifree] rebranding due to other TeXLive changes

what was decided? - shall we continue to re-package this, only to re-brand it - it appears that we are not "rebranding due to other TeXLive changes" - as theova points out, the other changes are not necessary, but a consequence of adopting the package

i tend to agree with theova, that it is probably not necessary - aside from the workload, this package is enormous - the each arch-specific src.tar.gz is 500MB

I think we have mixed policies regarding whether to rebrand arch-branded software to parabola or not. I don't recall whether there was a clear guideline to do either or the other. Maybe this is worth a separate issue to discuss that we can reference whenever this comes up again? Because I think there's a handful of packages where this discussion needs to happen.

What is the process to resolve such a question?

I see that there is slight tendency towards accepting the arch package. However I don't see objections/arguments against it. (Please correct me, if I'm wrong)

I think rebranding is necessary for at least the following reasons:
- to avoid misleading people into thinking Parabola somehow endorses Arch,
- to avoid steering people towards Arch, and
- to avoid repeating the "Arch Linux" mistake, which itself has two sub-issues:
-- the correct full name is "Arch GNU+Linux", and
-- Linux is nonfree; it has been blobbed since '96.

It's unfortunate the maintenance overhead is high for a relatively trivial yet important change, but what else can be done?
I doubt patching precompiled Arch packages is faesible.

none of these points, by themselves, are sufficient to require a re-package of texlive-bin by parabola.

these are things we fix on the side when addressing real freedom issues, such as non-free packaged code or assets.