After looking into it, I actually think chia lisp [1] gets pretty much all
the major design decisions pretty much right. There are obviously a few
changes needed given the differences in design between chia and bitcoin:

 - having secp256k1 signatures (and curve operations), instead of
   BLS12-381 ones

 - adding tx introspection instead of having bundle-oriented CREATE_COIN,
   and CREATE/ASSERT results [10]

Bitcoin uses the UTXO model as opposed to Chia's Coin Set model. While these are close enough that it's often explained as Chia uses the UTXO model but that isn't technically true. Relevant to the above comment is that in the UTXO model transactions get passed to a scriptpubkey and it either assert fails or it doesn't, while in the coin set model each puzzle (scriptpubkey) gets run and either assert fails or returns a list of extra conditions it has, possibly including timelocks and creating new coins, paying fees, and other things.

If you're doing everything from scratch it's cleaner to go with the coin set model, but retrofitting onto existing Bitcoin it may be best to leave the UTXO model intact and compensate by adding a bunch more opcodes which are special to parsing Bitcoin transactions. The transaction format itself can be mostly left alone but to enable some of the extra tricks (mostly implementing capabilities) it's probably a good idea to make new conventions for how a transaction can have advisory information which specifies which of the inputs to a transaction is the parent of a specific output and also info which is used for communication between the UTXOs in a transaction. 

But one could also make lisp-generated UTXOs be based off transactions which look completely trivial and have all their important information be stored separately in a new vbytes area. That works but results in a bit of a dual identity where some coins have both an old style id and a new style id which gunks up what 
 

 - serialization seems to be a bit verbose -- 100kB of serialized clvm
   code from a random block gzips to 60kB; optimising the serialization
   for small lists, and perhaps also for small literal numbers might be
   a feasible improvement; though it's not clear to me how frequently
   serialization size would be the limiting factor for cost versus
   execution time or memory usage.

A lot of this is because there's a hook for doing compression at the consensus layer which isn't being used aggressively yet. That one has the downside that the combined cost of transactions can add up very nonlinearly, but when you have constantly repeated bits of large boilerplate it gets close and there isn't much of an alternative. That said even with that form of compression maxxed out it's likely that gzip could still do some compression but that would be better done in the database and in wire protocol formats rather than changing the format which is hashed at the consensus layer.
 
Pretty much all the opcodes in the first section are directly from chia
lisp, while all the rest are to complete the "bitcoin" functionality.
The last two are extensions that are more food for thought than a real
proposal.

Are you thinking of this as a completely alternative script format or an extension to bitcoin script? They're radically different approaches and it's hard to see how they mix. Everything in lisp is completely sandboxed, and that functionality is important to a lot of things, and it's really normal to be given a reveal of a scriptpubkey and be able to rely on your parsing of it.
 
There's two ways to think about upgradability here; if someday we want
to add new opcodes to the language -- perhaps something to validate zero
knowledge proofs or calculate sha3 or use a different ECC curve, or some
way to support cross-input signature aggregation, or perhaps it's just
that some snippets are very widely used and we'd like to code them in
C++ directly so they validate quicker and don't use up as much block
weight. One approach is to just define a new version of the language
via the tapleaf version, defining new opcodes however we like.

A nice side benefit of sticking with the UTXO model is that the soft fork hook can be that all unknown opcodes make the entire thing automatically pass.
 

The other is to use the "softfork" opcode -- chia defines it as:

  (softfork cost code)

though I think it would probably be better if it were

  (softfork cost version code)

Since softfork has to date never been used that second parameter is technically completely ignored and could be anything at all. Most likely a convention including some kind of version information will be created the first time it's used. Also Chia shoves total cost into blocks at the consensus layer out of an abundance of caution although that isn't technically necessary.

[10] [9] The CREATE/ASSERT bundling stuff is interesting; and could be
    used to achieve functionality like the "transaction sponsorship"
    stuff. It doesn't magically solve the issues with maintaining the
    mempool and using that to speed up block acceptance, though, and
    the chia chain has apparently suffered from mempool-flooding attacks
    recently [11] so I don't think they've solved the broader problem,

Chia's approach to transaction fees is essentially identical to Bitcoin's although a lot fewer things in the ecosystem support fees due to a lack of having needed it yet. I don't think mempool issues have much to do with choice of scriptpubkey language. which is mostly about adding in covenants and capabilities.

That said, Ethereum does have trivial aggregation of unrelated transactions, and the expense of almost everything else. There are a bunch of ways automatic aggregation functionality could be added to coin set mempools by giving them some understanding of the semantics of some transactions, but that hasn't been implemented yet.

I previously posted some thoughts about this here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019722.html