Lock-in. VMware addressed the question of lock-in to my satisfaction. Because the platform is open source and there's a broad ecosystem of compatible providers (examples include CloudFoundry.com, Micro Cloud Foundry, AppFog, and Tier3), developers can easily move applications between Cloud Foundry instances, both on public clouds or private infrastructures. VMware noted that in addition to the multicloud flexibility, this open source flexibility ensures that developers and customers aren't locked into one cloud or one platform. As proof, the company pointed me to a blog post on extracting data using the Cloud Foundry data tunneling service, which is far and above "You can dump it to CSV and port it yourself."
Security. We were unable to find any published documentation on security certifications (PCI, SAE, and so on) for Cloud Foundry. VMware pointed me to its User Authentication and Authorization service, which appears to be a single sign-on scheme based on OAuth2. This could be a helpful service for application developers, but government organizations and large companies are going to require VMware to provide documentation of security certs before migrating to its cloud.
Who's using it? Cloud Foundry is well positioned to meet the needs of companies that want a combination of public and private PaaS. Its focus on an ecosystem of Cloud Foundry providers is a strong point, especially with regards to lock-in. Cloud Foundry is clearly aimed at Ruby, Node.js, and JVM-based languages. If you have a more diverse technology base, this may not be your first choice.
VMware pointed me to several published case studies, including Intel, Diebold, AppFog, Cloud Fuji, and others.
How did it do? We installed the Eclipse plug-in, deployed the WAR, and changed nothing. In fact, the first time we deployed Granny, we accidentally deployed it configured with CloudBees' JDBC information. Cloud Foundry automatically detected our Spring configuration and reconfigured the database settings for our Cloud Foundry database. This kind of magic may make some people nervous, but it worked seamlessly.
Conclusions. Cloud Foundry "just worked" -- we did nothing to the application but install an Eclipse plug-in. What's not to love? For ops teams, there's also a command-line interface. Once this PaaS launches, depending on pricing and such, it will certainly be a viable choice for Java developers. We can assume that for Ruby, which Cloud Foundry is written in, you would have a similar experience. (We have also tested the Node.js interface, which was a little trickier but still very workable.)