Hey @Josh_E_Wa !
Pleasure to be conversing with you yet again - It’s a positive sign to see faces from the Foundation contributing here! I shall address your questions below:
Re. Point 1 - this is most effectively achieved by virtue of updating the corresponding Github repos that contain the code to the respective Front-end - with updates to the underlying SDK/Frontend Kit being communicated through GitHub + other community channels. In Liquity, Frontend Operators are given two options - to launch a Frontend using their Frontend launch kit, or alternatively, you can also use the Liquity Frontend SDK and the middleware library they provide to create your own front end application. Hence, you could either opt to provide for one type of frontend, or allow for iterations of that frontend as even pointed out by @foxlabs (as you can see there are multiple iterations/integrations here https://www.liquity.org/frontend#frontends).
At all stages however, (naturally) the function of the Frontend is still as per the above image ^
Re. Point 2 - There isn’t an agreed-upon lower or upper threshold to assess frontend decentralisation/centralisation (these thresholds are not even present re. PoS Blockchains vis a vis nodes). We have to consider that frontend decentralisation is actually a novel concept and thus, we would actually be setting the standard (together with other Protocols like Liquity), in regard to FE decentralisation. With regard to the flow going through each, we would have to come up with a system that takes into account a balanced-incentive model wherein users are incentivised to use front-ends with a lower usage rate with the possibility of achieving a form of incentive by using such a less-used FE. This is the same concept that is prevalent in certain LPs/Staking Modules - wherein popular LPs/Staking Modules have lower APYs and lesser-used LPs/Staking Modules have a higher APY intended to trigger further deposits (conducting research in this regard would be very interesting). Finally, I would opine that I deem node count and FE count to be equal in importance. However, one phrase that rings ever so true in mechanics such as this is that the more, the merrier!
Re. Point 3 - I personally do not see any conflict of interests with a node operator for example - also being a frontend operator. Actually, I would opine that at the initial stages, I would encourage each node to set up and host its own separate FE. The only concern I have with regard to FE hosting is with the Foundation/Trading operating a front-end (concern is mainly based on regulations + decentralisating certain key and pivotal roles from these entities). I would suggest that the Liquity approach is taken and that dYdX Trading Inc. for example actually winds down the FE it hosts and decentralises this key function to the community (I created a high-level post on decentralisation and its pre-requisites here: IL Rants #1: Understanding Decentralisation).
I hope I addressed your points as effectively as possible. If I missed anything or something is unclear please do reach out!