1. The idea of @FunctionalInterface leveraged practices that were already in use--interfaces with a single method--for Comparator, Runnable, Callable, and external libraries. This meant that users could use lambdas to implement such interfaces immediately, with no changes to existing libraries.

2. The actual implementation of a lambda in bytecode is a single invokedynamic call. They went that route to avoid tying the bytecode representation to their initial implementation.

A future change could add true function types, and have them automatically instantiate a target functional interface (provided that they have the same "shape"). That would require a language change (adding function types), but not a bytecode change.

That would have the nice result that all the code that people are writing now could work with new function types, and new code could be written to accept the function types instead of functional interfaces. My library would become unnecessary at that point, and I would be pretty happy about that.

That is, Java 8's lambda implementation does not preclude fully-backwards-compatible "real" lambdas in the future.

Personally, I think the Lambda project was a well-reasoned, intelligent step forward. The video is really worth watching, because I wasn't aware of how flexible their future directions are until I watched it.