As a long-time Lisp user I have a few thoughts about that.
Developing a new operating system is tough. Doing it on your own is tough squared. (Getting support from IBM does not help.) That's what Apple experienced with Copland. I fear that moving to a memory managed language and an API based on that is also very tough.
With NeXT OS (then Mac OS X) Jobs built on existing technology and added a few crucial things (Objective-C based libraries, User Interface Designer, ...). But he failed to get important points of the more elegant Mesa, Smalltalk and InterLisp-D systems he saw at Xerox PARC. Especially Apple failed to fully understand the base software and operating systems from those and the technology used to built them.
Java is very similar to some Lisp implementations internally (Garbage Collection, Virtual Machine, ...). Java additionally had lots of companies investing into it, so in some areas it added lots of features (security, standardized byte code, ...) . Companies are exploring the combination of several technologies which creates a very complex software environment (just look at the J2EE application servers from Bea and IBM). Still my biased feeling is that Java (and its environments) is bloated, complex, applications are extremely costly to maintain and programmer productivity is low (if you look at the whole software lifecycle). Literally billions of dollars have been invested into the Java infrastructure by SUN, IBM, Apple, BEA, JBOSS, Borland, JetBrains, Oracle, SAP, Macromedia, even Microsoft. Still I don't have the feeling 'this is it'. Apple seems to lower the support for Java, since it won't provide Java integration for new libraries.
Now we see Microsoft adding a few Lisp-like features to the C# language (closures, code as data, ...). They also have their own software infrastructure, where they invested billions of dollars: .net . The approach is a bit different from SUN (where Java is the preferred and supported programming language. The Java Virtual Machine has been designed to run Java programs and it has not been designed to efficiently support dynamic languages. Though this has been requested early on.) Microsoft doesn't force you to use a particular programming language, they even designed the Common Language Runtime to be kind of language neutral (as a feature) - but you have to use the infrastructure. Still it is not language neutral enough for an efficient Common Lisp implementation. Using this infrastructure also basically means that you have to use Microsoft's Windows operation system (one alternative would be Mono). Lisp companies are not building their Lisp implementations on top this Microsoft infrastructure. I wonder if this is a big mistake for this particular market? Currently Microsoft has its own software crisis: Windows Vista. This is an indication that their current software infrastructure is not bringing the complexity down and that they have a hard time dealing with the complexity. I don't think Microsoft's infrastructure is something Apple wants to adopt.
Apple already has Objective C and Applescript. But the basic infrastructure is relatively primitive. For example memory management in Objective C is primitive. It just provides a kind of reference counting. Reference counting is especially bad when you combine it with Objective C. Some of the basic libraries are not multi-threaded. And so on. I agree that library and API design is not one of the strong points of Apple. Apple is also the only company of interesting size, that works on an Objective C based infrastructure.
Then we have a few programming systems that got (relatively) popular (more or less) recently: Python, Ruby, Perl, Javascript and probably others. Many have their share of Lisp-features (dynamic objects, dynamic typing, reflection, garbage collection, virtual machines, ...). At the same time they always provide a compromise and don't offer a solution to problems like 'efficient' garbage collection, native compilation, and others. Mostly they are designed to be used together with C-based infrastructure and APIs. Apple currently seems to use Python for some applications.
So it seems that there is no (available, mature, scaling, ...) technology, that Apple could use out of the box to avoid the Copland-2010 scenario. Well, they could go back to some of the oldtimers like Lisp, Smalltalk or even Dylan. Still these currently don't have the all necessary infrastructure due to the lack of investments in the recent years. So again a huge investment would be needed. Plus these languages and their infrastructure are not very popular currently. I guess we will just have to live with this messy situation for a long time. For example adding a good garbage collector to Mac OS X would be very hard. I have to say that I really miss the Newton OS, since it already had quite a few good ideas implemented.
Still, there is a lot that Lisp has to offer. To name a few things:
a) Runtimes with support for multiple programming paradigms: Imperative, Functional, Logic and Object-oriented Programming.
b) Runtimes with support for both Interpreters and Compilers.
c) Extensive Foreign Function Interfaces.
d) Sophisticated Garbage Collectors plus other memory management techniques.
e) Runtimes with support for very dynamic objects.
f) Interactive Programming Environments.
So, probably one would need to think about an approach that is less general and provides a new infrastructure that can be used in some combination with the old libraries and APIs. This then will generate all the integration issues currently Lisp systems have to deal with. Lisp-bases memory managed data structures are simply different from what the host OS is using. For example most data structures in Lisp systems are using special tags to identify its type. We need a robust answer for that.
So, what are the implications for the Lisp community?
a) Improve the runtimes and libraries running on Unix-like operating systems. Standardize some.
b) On Apple's Mac OS X: Integrate the Cocoa/Carbon libraries nicely and robust with a CLOS-based API. Standardize one Cocoa bridge across Lisp implementations.
c) Rethink the integration issues for the Microsoft infrastructure (.net). What would be the long-term solution that benefits users on this platform most?
d) Provide better tools for Lisp programming for Mac OS X, Linux and Windows.
e) Improve the quality of the free Lisp software (which is often quite bad). Define common quality standards (and tools) for Lisp software (documentation, architecture, testing, naming, portability, installation, ...).
f) Improve the basic infrastructure (compilers, threading, ...).
g) Develop a few demonstration applications.
So maybe the Lisp community can benefit from the search of developers in the coming years. Their search for better infrastructure, better programming experiences and better programming languages.