Regarding brc-20 and the inscription number debate. In the case of an imminent merge by the ord core team the following can be assumed.
The brc-20 protocol will not recognize any cursed inscription content retroactively blessed into the ordinals protocol.
However, being wary of making definitives based on lack of information and on short time frames this is subject to change prior to a merge. We are actively monitoring the situation and welcome all discussion on the topic.
Many have used the term “snapshot” but I think best method in case of previously cursed recognizance is to define a block height at which the protocol updates the ruleset to parity with the ord reference client.
There could be an additional coordinated indexer snapshot taken to use as reference for state in case of further confusion.
I’d prefer prioritizing UX > metaprotocol DX > protocol DX.
In case of a retroactive blessing, the BRC-20 protocol would better mirror the development of ord the way @cbspears suggests. Not only BRC-20 would better keep up with this update but it should keep parity with ord forever. Otherwise, users would need to learn that not all inscriptions are the same, some BRC-20 inscriptions are valid and some or not, without an easy way to distinguish.
There are multiple ways a solution could look like. Simplest being: brc-20 indexers should only recognize inscriptions that are recognized in version 0.9 and below (and then define what that is precisely).
define a block height at which the protocol updates the ruleset to parity with the ord reference client
Whilst I’d love continued parity (recognizing all new inscription types moving forward), my concern is that this is not a one time event, and we have to run this debate back every x months/years.
I second @domo 's idea of freezing the ord version to ensure no brc-20 event is blessed retroactively. What matters to a fungible token is its spending history, i.e. the ordering of the events, not the uniqueness of each of the events. If something can be added retroactively that changes the ordering of these events, it’s equivalent to rewriting the spending history, which is not acceptable.
An immutable spending history is a necessary condition, whereas continued parity (though I love it, too) is a good-to-have.
At the end of the day, an immutable ledger is the foundation of decentralization.
And doubly so when it comes to a unit of account. If you don’t have a reliable accounting of the unit, you don’t have much, no? BRC-20s are only the accepted order of past events.
Whatever future approach is taken, if any, to reach parity with the ord reference client, ignoring cursed inscriptions is the only real option for BRC-20 at this time.
We should let BRC-20s evolve to a solution naturally as devs/teams reckon with the work at hand.
For now, based on the issues with ord 0.8 (and their proposed solution), it’s my opinion that the retroactive cursing of inscription content may not be recognizable either.
We can be almost certain that there will be numerous coordination challenges for BRC-20 state in the months, perhaps years going forwards.
It’s much simpler to define a state ord version, say 0.4.0 or 0.9.0 and consider recognized inscriptions from that version BRC-20 “canon”.
Regardless of the 0.8 issue, this has been my thinking for some time. brc-20 inscription definition can not be mutable retroactively.
Conversely, in the past month, ord has received two proposals aiming to retroactively modify this definition, one aiming to safeguard number stability and the other seeking to disrupt it.
I really think that it would be better if the jubilee is processed and blessed inscriptions are just ignored. As far as I know, those inscriptions will all get blessed on a block that’s far away from the block they were mined, so it should be relatively easy to identify them. If brc-20 was tied to a specific version of ord, it should be the one after the jubilee. Here are the reasons:
These benefits would drastically improve the cost and efficiency of the protocol and I don’t think they should be ignored.
I’m sorry for this, What are cursed inscriptions?? 
Most of the articles I’ve been seeing are not explaining this well @domo or anyone know a source I can read
Hi Everyone! I am a proud owner of the first and last cursed 10k project on CBRC: CybordPunks! Excited to be part of this project on a new chain!