There seems to be a general misunderstanding about how the specs are intended to work. You standardize on things that as a group everyone has agreed would work in a specific way. Right now, the CDI EG is innovating and standardizing on those innovations instead of standardizing on the features already available in the various impls. Lets take a few examples of where impls deviate from the specs.
- JAX-RS : All of the implementations had client impls paired up with their 1.1 compliant releases, even though it wasn't required. Why? Because it made a ton of sense. Then see what happened afterwards, the EG came together and standardized on a Client API that took a lot of the great features in each impl and made them consistent.
- EJB: Lets not forget that the removal of home/remote/local interfaces came from a combination of xdoclet and spring. The EG came together, saw that what was in use and figured out how to standardize on it once the language features were available.
- Singleton EJBs: An extension of EJB 3, most vendors supported a form of singleton in their EJBs, and the EJB EG agreed upon it in addition to some concurrency issues that had to be addressed.
- JPA: Lets not forget that HIbernate supports in dual hierarchies the EntityManager and Session interfaces concurrently. Want to use HQL in your @NamedQuery? Sure, it works fine.
Bottom line, we need to get these features out into the wild, let people play and come back with input on the various impls. There's nothing stopping the weld team from introducing org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and CompletionStage, allowing app developers to consume this via an injection point just like Event works today, @Inject AsyncEvent<Foo>. Even if thats not the spec compliant way to do it long term, it makes it clear that you're using a provider specific API.
In addition, there would be nothing stopping either team from introducing support for @Priority on observer methods. There's no API change, no spec change required. The spec doesn't mandate that it works, but there's nothing stopping your impl from allowing it. The spec doesn't say you absolutely cannot leverage it.
John