Good point! I am aware of that proposal, but as one author noted "[the proposal] aims to be an equivalent of static or compile-time reflection" in a post of the pitch thread. Instead, this proposal aims to tackle a very specific case: conformance synthesis for structs. The other proposal also supports enums and takes a very different approach altogether.
ABI Impact
I will add a section about ABI impact and API resilience, but first I want to answer your question.
The proposal you linked to is based on a Structural protocol that enables auto-synthesis of an AST-like data structure. As a result, ABI is impacted by conforming to Structural and structuralRepresentation can be overridden — which isn't always desirable.
On the contrary, this proposal offers a compile-time feature, really similar to result builders; hence, it has no ABI impact or way to override the type structure passed to the macro.
Diagnostics
A major criticism of the Structural proposal is the handling of diagnostics. Namely, The AST-like structure is quite "opaque". That is, the compiler can't really understand what property maps to which StructuralProperty after the construction of structuralRepresentation, leading to very limited diagnostics.
This proposal, however, is very similar to result builders, in terms of how properties and components, respectively, are passed into the micro features. Function builders have evolved dramatically from the developmental @_functionBuilder attribute and now provide substantial diagnostics. For example, we get relevant diagnostics when a component does not conform to a type or when the builder can't accept more parameters.
Likewise, result builders will hook into similar mechanisms for generating targeted diagnostics at compile-time, which can be informative and indicate directly which members prevent auto-synthesis — as is currently done for synthesized conformances.
Representation
StructuralCons is constructed with the name of a property, its value, and boolean indicating its mutability. This isn't very expressive, in my opinion, not to mention that Swift has KeyPath, which is apt for representing properties.
Furthermore, with a key path returning a String path, as discussed here, Encodable, and perhaps Decodable with a future addition, could be implemented with conformance builders.
Ergonomics
This proposal directly targets conformance synthesis and tries to simplify it as much as possible. Ergo, implicit conformances are a major design aspect of the proposal. Lastly, there is the custom conformance-builder attribute, which allows for flexibility in terms of the synthesis strategy (this is very useful for custom serialization, etc.).
This was a typo, thanks for pointing it out!. The non-transformed enum is supposed to be:
enum Inputs: @EncodableBuilder Encodable {
case number(Double), text(String)
}