I am absolutely fine with specifying in TOSCA that BPMN 2.0 is the default language for defining plans.
Wrt "artifacts", we need be more specific.
We define "implementation artifacts" as the "executables" realizing operations. The spec lists potential types of operations, i.e. WSDL port type operations, REST interfaces, and scripts. WSDL port types are often implemented as servlets but also as EJBs (in addition to corresponding Windows components). Thus, we should add EARs to Derek's list. REST interfaces are often realized as servlets, i.e. from a Java perspective JAR files or WAR files should be fine. The list of script languages is fine with me, but I need to delegate the list of scripts to others (this is not my skill area).
We define "deployment artifacts" as the "executables" realizing node types/templates. When a node type/template represents infrastructure, i.e. OS or middleware (DBMS, App Server,...) assuming images is fine. The list of VM image formats to be supported needs to be discussed. Also, we need to include AMIs (or references to them) because of their frequent use. But if we move from infrastructure up towards the implementation, we need to support artifacts that represent service- and process-oriented applications. Thus, the artifact types include WSDL files, BPEL- and BPMN files, EAR/JAR files (implementing the WSDL port types) and so on.
Summary: The list is an excellent base, but we should consider to extend it in order to reflect applications that are often (expected to be) run in a cloud environment.
TC approves closing this issue without further action on 9/6 (see https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46841/TOSCA%20TC%20Minutes%202012-09-06.docx).