As a replacement for paper, something like this makes sense v.s. what you do with a ledger presently.
However, shamir's shares notoriously have the issue that the key does exist plaintext on a device at some point.
Non-interactive multisig has the benefit of being able to sign transactions without having keys in the same room/place/device ever.
I agree that that interactive multisig is best for transactional recovery, but there is still a place in our tool chest for Shamir split backups especially in operational security scenarios, but as you state, you must be aware of the limitations of Shamir, not only from the fact that there is vulnerability in that you must restore keys in one place, but also there are denial edge cases where when you only have k-1 of n, someone can deny you knowledge of who gave you the corrupted share.
Right now the best C-library for Shamir sharding of recovery seeds is at the Blockchain Commons Github
https://github.com/BlockchainCommons/sss/blob/master/README_slip39.md however, this code base needs refactoring to be a good standalone library. This requires us separating out the Shamir portions from the SLIP-39 mnemonic elements and command-line elements. We also want to separate out the randomness portions of the code so you can test different implementations against deterministic randomness to ensure they give the same value (but don't use this for production!) Once this is complete, we will be submitting this library for formal review.
We are also working on air-gapped open-source open hardware for seed creations and Shamir restoration. For instance, this device has no wifi, Bluetooth, or persistent memory, and the serial port is disabled. It is sized to fit in a bank safe deposit box. See
https://twitter.com/ChristopherA/status/1175465994644574208?s=20
Longer-term for seed sharding, we want to leverage the VSS (Verifiable Secret Sharing) that future Bitcoin musig uses, which we believe has advantages over Shamir Secret Sharing. It can be used for both traditional sharding, but also for musig transactional recovery without restoring of master seeds on a single device, and it is easier to prove that shares are live and avoid denial use cases.
All this being said, we recommend Bitcoin multisig transactions as the best solution for self-sovereign recovery of funds vs using Shamir (or SLIP39). Lately, we've been working on PSBT and bitcoind descriptor support in our alpha bitcoin wallet for iOS, FullyNoded 2
https://github.com/BlockchainCommons/FullyNoded-2 — in theory, this iOS wallet can facilitate any scenario that bitcoind supports as a descriptor as it communicates with your own private full-node over Tor v3.
P.S. If you've not seen it yet, our free #SmartCustody book
http://bit.ly/SmartCustodyBookV101 offers what we think are current best practices for single seed recovery. We did not include multisig scenarios in v1 of this book as at the time they were too difficult and error-prone for most people. We are now working on v2 of the book which will cover multisign and fiduciary scenarios now that PSBT is maturing and more wallets are improving multisig support.