Well yes, two different inflation rates and an ongoing ability to swap 1 ETH1 for 1 ETH2 is the issue, as far as I see it. I don’t see how a fixed peg would work in this situation and although you say it would work “Period” I don’t see how. What would you expect to happen the first day the beacon chain starts validating in this scenario?
I could see a floating exchange rate work (start at 1:1.2, for example, and move to 1:0.1 over time); if the change in the rate is known in advance it would allow market forces to move ETH1 over to ETH2 at the time they are comfortable with it (a later date would involve less risk but lower reward).
Eventually the exchange rate has to go to 0 or there be some mechanism in the deposit contract (or beacon chain) to stop accepting new deposits, as otherwise we could reach a state where the ETH1 chain is basically abandoned and someone can run it in their basement generating ETH1 and depositing them for ETH2.
(There are meta-constraints here, as well: we don’t want to see 100% of ETH1 being deposited in to ETH2 early on because then there will be no way of paying gas on ETH1, for example.)
You can think of the two systems in parallel as each having some issuance (the eth1 pow issuance and the eth2 pos issuance). For some time, both issuance sources are increasing the total eth supply and paying for two separate system level services.
Eventually, eth1 is to be forked into eth2 as an execution environment (EE) with the total ether balance of eth1 also forked into this EE. At this point, the pow issuance disappears, the eth assets that were separated in eth1 and eth2 are reunited in the same system, and the low pos issuance continues on to secure the unified eth2/eth1 system.
During the time in which eth2 exists before eth1 is forked in, there is an additional cost in inflation to secure the pos and pow components simultaneously. This is a minor cost (likely significantly <1% inflation per year) for a conservative roll-out. Eth2 can rolled out in phases and vetted in production prior to eliminating the need for eth1 pow miners.
I think the true reason ETH 2.0 is a separate token, is because ETH 1.0 miners would never agree to shovel some of ETH 1.0 minting into ETH 2.0 awards. An attempted hard fork like this would fail with ETH 2.0 on the minority side.
The system has been specifically designed to avoid negotiation with miners. The price paid though was that ETH 2.0 is a totally different thing, pretty much having no relationship to ETH 1.0
If we want to make sure it stays one currency even before migrating 1.0 to an EE, then one way is to allow transfers of BETH back to ETH1 as soon as we’re finalizing 1.0 with the beacon chain. Just burn on beacon and mint on 1.0.
Seems reasonable to have the rule that 1 ETH can always be converted into 1 BETH.
This means that the total supply of BETH at time t can be considered to be the total supply of ETH at time t plus the sum of any block rewards from both the Beacon and Mainnet chains until time t.
It does mean that the value of BETH will always be less than or equal to the value of ETH, with the value of ETH essentially capturing any additional value (i.e. utility) the beacon chain delivers.
Whilst there is no easy liquidity in BETH (i.e. it can’t be moved around) the market value of BETH probably doesn’t really matter. Your decision on whether or not to convert ETH to BETH is a function of your estimate of the proportion of network utility that gets delivered to BETH and the staking reward - for people who believe in Eth2 there would be strong motivation to move across.
Once there is a liquid market and natural demand on Eth2 for BETH with little perceived downside / risk to the Eth2 chain, then people will naturely move over to gain direct utility and staking rewards.
One factor to consider is whether there is a social contract that the bridge runs forever - it isn’t essential but would skew the above close to the bridge close date.