OK, I did not realize this. I'm looking at the spec for TOSCA 1.2 and 1.3 on this ([3.8.8]) and it's very confusing.
TOSCA 1.2 supported two notations, one for a "normal" mapping to a template, and another for mapping to inputs. In TOSCA 1.3 the first notation was removed, likely to remove confusion ... but it also removes this feature, so now it's impossible to map properties to anything other than inputs. Attribute mapping remained the same (map to an attribute or an output). Also it seems that attribute mappings allow for mapping to capability and even relationship attributes (nested).
This seems to me a hijacking of the properties feature (and attributes for that matter) for an entirely different purpose. Moreover it would require the node type to be designed in such a way that it would have to match inputs ... or vice versa. This seems a very roundabout way to solve the problem.
I'm inclined more and more to think that we need a very different grammar for linking the consuming service and providing service.
I think what we need here is a way for the providing service to "expose" features and also for the consuming template to "inject" them. These features thus become "shared" between both services. And I think Adam's proposal is the right starting point, something that looks more like a node template than a node type, something that can be constructed rather than "mapped".
One major problem with the current grammar is that mappings are one-to-one, but real world use cases are ... more complicated. But also more simple in terms of defining what users want. Here's a simple example: imagine a providing service that has two nodes, an application and a database, and that boths of these can be installed on the same server. The consuming service doesn't care that internally the providing service comprises several nodes, all it wants to do is specify "install this (whole) service on this server". There is no way to do this with substitution mapping, because you can only map the installation requirement of either node template, not both of them at once. There's this mismatch between "mapping" and the control of the actual features we need.
Allow me to try to solve this with some back-of-the-napkin brainstorming by building on Adam's proposal and my idea of "exposing":
# Providing service
topology_template:
 inputs:
ÂÂÂ cores:
ÂÂÂÂÂ type: integer
ÂÂÂÂÂ default: { @get_property: [ app, cores ] }
 node_templates: app:
ÂÂÂÂÂ directives:
ÂÂÂÂÂ - expose # shared with the consuming service
   type: WebApplication # this type derives from "Application"
ÂÂ ÂÂ properties:
 Â Â name: { @get_property: [ database, capabilityname, name ] }
ÂÂÂÂÂÂÂ cores: 1
ÂÂÂÂÂ attributes:
ÂÂÂÂÂÂÂ id: { @get_attribute: [ database, capabilityname, nested1, nested2, id ] }
ÂÂÂÂ requirements:
ÂÂÂÂ - host: my-host
  database:  type: DB
ÂÂÂÂ requirements:
ÂÂÂÂ - host: myhost
ÂÂ my-host:
ÂÂÂÂÂ directives:
ÂÂÂÂÂ - expose # *also* shared with the consuming service
ÂÂÂÂÂ type: Machine
# Consuming service
topology_template:
 node_templates:
ÂÂÂ myservice:ÂÂÂÂÂ type: Application
ÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂ cores: 5 # this will and override the value (our values here are higher priority), and thus also the property, which will then affect the input
ÂÂÂÂÂ requirements:
ÂÂÂÂÂ - host: my-vm
ÂÂ my-vm:
ÂÂÂÂÂ type: VirtualMachine # this type derives from "Machine" and the node will be "injected" into the providing template
If you follow this example you'll see that rather than substituting a single node, we are instead "exposing" *two* nodes from the providing service. Once exposed they are essentially "shared" between the two services. The node template names are different but as long as the matching can be done correctly (by policy?) they should end up referring to the same exact node representations. Also note that the node types have to be the same or *derive from each other*. Of course references to the base type won't be able to access features of the derived type, but that is intended by design. So the consuming service only knows that this is an (abstract) "Application", while the providing template uses "WebApplication" and refers to additional properties and attributes. On the flip side, the providing service knows that it connects to an (abstract) "Machine", while the consuming service provides a concrete sub-type, "VirtualMachine".
The magic of sharing means that we can indeed install both the app and db nodes on the same server. And we're no longer talking about "substitution nodes" but rather a more open sharing of one or more nodes between the two services.