The html/CGI/script web application environment has been very successful at providing interfaces to applications and services. This platform is limited in a number of ways, security, client pull, document centric API's, limited form interaction.
Web documents cannot be trusted, they can't be allowed to access client file-systems, or resources from other URLs, or attached devices such as cameras, printers etc.
Web applications often do need to access these resources to provide the kind of features users demand, or for efficiency. Any web application framework will need a mechanism for getting informed approval from the user of any privileges it requires. This is the most important part to get right, but very difficult, educating uninformed users to make decisions on what to trust a web-application to do is not a problem I've yet seen solved in an acceptable way.
Users are used to certain interface conventions, they're used to the ones used by their window manager (or other operating system) and they're used to the ones provided by their browser. Using either can generally be successful and understood by users, however the set provided by the browser are generally not rich enough to enable efficient interaction with an application.
When a traditional application can't be installed on a platform, it's instantly obvious, it's possible to check before installing that everything necessary is there, bugs are generally easily reproducible as the number of platform and configuration variables are scopable, and easily reportable. Web applications on the other hand will have users attempting to run them on any platform, in any environment with any settings, reporting and reproducing errors becomes harder, and even testing to see if the application will generally work is often difficult. Users often find themselves half way through using an application with considerable investment in the product before discovering they simply can't use it.
Current web apis focus on the document, for applications richer APIs are required which provide access to:
A richer specification of user interface controls than provided by existing HTML specifications could be done, however my experience suggests this would not be a good idea. Declarative components over script based components based on simple primitives suffer from the problem of requiring complete conformant implementations before they can be used. Script/primitive solutions can be layered up such that the simple components can be built that will work and degrade on a variety of platforms, this places some of the burden of designing the UI controls on the application author, but reduces the load on the host authors, which makes the hosts proliferate onto lesser used devices easier.
The design of rich components is an opportunity for application tool development IDEs to develop them to reduce the load on end users. A mechanism to specify UI controls in a meta language with the rendering provided by the script/primitive renderings will allow host languages to provide optimised renderings of those UI controls specified by the meta language. This approach provides the best of both worlds, cheap to implement for authors, and the opportunity for optimised performance in hosts.
A common default list of native components may be valuable to allow authors to specify native components should be used, but this would need care as layout of native components becomes more difficult.
Currently vendors have provided a variety of mechanisms for requesting extra permissions to use specific apis, a standard mechanism for requesting and being granted privileges will enable users to educated, and more host platforms targeted.
Existing standards exist mainly in the Document scope, application scope needs to be extended to provide unified interfaces that are currently provided by many hosts that work outside of this document and allow for the interaction within the document, not with the user and his devices.
Work to standardise and extend what is currently provided by the Window object of common web user agents would be very valuable, it would require a considerable amount of security related work.
Investigation into declarative web application work would not be particularly valuable as declarative mechanisms do not have sufficient error handling ability to cope with the wide variety of environments that a web application would be exposed to without basically becoming a script language in itself, which is not useful when well known languages are available for the job.