On the one hand, I am deprecating component-property in ASDF3,
Why? What will be the new mechanism for what component-property provides?
I propose that any data that component-property is actually used for should be in appropriate slots of the system.
This will introduce a new round of synchronization headaches whenever a new slot is added. The existing mechanism is forward and backward compatible indefinitely.
Synchronization is NOT necessary to add new slots. If you want a new slot, just create a new class with that slot, and use both :defsystem-depends-on and :class in your defsystem form. This usage pattern wouldn't work on ASDF 1 or early ASDF 2, but it works quite well since ASDF 2.016 from June 2011 and later. Then, a year after your slot gets merged into asdf:system, you can stop using your defsystem-depends-on.
The properties mechanism is already totally and irremediably useless. Automation across systems is impossible unless everyone agrees on a schema, or you somehow merge the zillions of possible ad-hoc schemas; but properties actually make synchronization *harder* than lack thereof, by making it cheaper to diverge and more expensive to converge. Properties without a synchronized schema are useless within a single system, where it is easier, safer and more powerful to just directly store data in a Lisp variable rather than in the properties.
In other words, properties not only do not serve the purpose they look like they are addressing, but cannot possibly serve any purpose. They are a lure and a waste of everyone's time — an attractive nuisance.
I propose they be replaced by the real thing, i.e. agreeing on a schema. Before we do, we would be well inspired to look at similar metadata schemas from Debian, RPM, Hackage, PLaneT, etc.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Failure is the opportunity to begin again, more intelligently. — Henry Ford, who had two flops before founding Ford Motor Co.