I looked through the electrum source code and experimented a little, and this can actually be fixed very easily in the code:
https://github.com/spesmilo/electrum/blob/bc3013caf0d3d6a35290e9cc9e51125b7d03d14c/lib/bitcoin.py#L166

Line 166 :
        is_hex = (len(seed) == 32)

Change to:
        is_hex = ((len(seed) == 32) or (len(seed) == 64))


Line 170:
    return is_hex or (uses_electrum_words and len(words) == 12)

Change to:
    return is_hex or (uses_electrum_words and (len(words) == 12 or len(words) == 24))

Making these two changes allows 256bit hex code w/ to be used again in the style of https://bitcointalk.org/index.php?topic=153990.0

Would this be reasonable?

I used your method, restoring in 1.9.x (worked) then opened in 2.0.2, but upon opening in v2 there were no addresses listed. All this was done offline on an airgapped machine. However upgrading through the master public key from 1.9.x -> 2.0.2 works on the online watch-only wallet.

I don't mind having to do a migration to using different addresses, but I would like to keep the same seed as little changed as possible. Having to add some words to it to clear the checksum is fine.

My problem is that I used 1.9.x by providing it a hex string. This string is then turned into the 24 word seed. In v2 I can also no longer provide hex strings to recover the wallet.

What is the algorithm in v2 for generating the seed from a set of master hex bits? If there is some method to go from that string to a new seed that would also work.

f(hex string) -> seed

I'll look into the make_seed method you mention.

Thanks. Yes I've read a warning about using non-12 character seeds, but this was unfortunately the only path I could use at that time.

Is there a way to modify this seed (like how v2 uses an extra word) so that it will contain the version/checksum and can still be directly entered into v2?

I use a 24 word seed that can no longer be recovered using Electrum 2. This was originally generated from a hashed random sequence and the hex was fed into Electrum 1.9.x to create it.

Unfortunately with the release of 2.0 this wallet is no longer recoverable. Will this be fixed in a future release? This is rather important as I cannot recover the wallet with 2.x at the moment.

So that means those who created 24 word seeds (by entering raw hex) would have to do a migration of all funds to the new style wallets? However, the legacy seeds will continue to be able to recover a wallet even if BIP39 is implemented? (due to the hashing of the seed)

I highly recommend implementing WarpWallet hashing (with salt) if the purpose of creating the hashed seed phrase is to better support brainwallets.

+1

How would the implementation of BIP32 (and possibly BIP39) in 2.0 affect the ability to recover old-style wallets? Would there be an option in 2.0+ to specify the legacy deterministic wallet and legacy seed?

Related: Would there be a tool to enable migration of cold storage wallets from the legacy deterministic generator to BIP32?