What you describe still trusts the distributor - you just found a way to make the distributor easy to trust. I'd be more interested in a mechanism that is mathematically correct, like some of the papers referenced elsewhere in this thread.
You need a trusted machine to do operations with the key, and if you are going to build that anyway then you might as well use it for generation and distribution too.
I mean, if we all agreed to perform the decryption, the secret's out anyway. But not before then.
The real world use cases I most commonly support are things like CAs, TLS keys, financial transaction signing keys, and sensitive document decryption keys. All of these require single keys to exist that needs to perform automated operations, and needs to be on systems that can be backed up, restored, upgraded, and maintained, while able to prove no single person can access or control the keys.
The scheme I described can allow one key to be created, split, restored, used, and split again many times without full trust in any individual.
Splitting the key safely is only part of the problem though, because you will then need a system that only -uses- the key in a way all parties consent to.
Threshold signing is a much easier alternative for many use cases but sometimes a cryptosystem requires just one key and SSSS is all we can do.
To avoid any single party knowing or controlling an SSSS split key you can:
1. Write an application that takes N public keys as input, and returns a newly generated SSSS split key with the shares encrypted to each respective public key as output.
2. Build application deterministically as an immutable unikernel or firmware image for hardware that supports remote attestation (Nitro Enclave, Convidential VM, HSM, etc).
3. Publish source code such that all participants can access and review it, or confirm review was done by multiple parties they trust.
4. Have multiple parties build the application bundle and confirm they get the same hash
5. Any party deploys the bundle to a live remotely attestable system.
6. All parties use the remote attestation interface to confirm the target system is running the same image they compiled themselves.
7. All parties submit their public keys
8. System generates key, splits it, and returns SSSS share to each party encrypted to their respective public key.