It seems that a variation of the first two options ("Bare Filenames" and "Keywords") would be best.
1) A profile author would use the TOSCA "namespace:" keyword to give the profile a name. We briefly discussed the usefulness of establishing a convention that would help in avoiding name conflicts. Java package naming conventions might be a good inspiration. So, names like this, perhaps:
org.etsi/nfv-1.1
The domain-name-like organizational prefix could allow different for using the same shorter name for profiles ("storage", "nfv", etc.). Again, this works pretty well for Java. Conflicts, if they ever do happen, can be solved via the usual social process. :)
Example of a profile header:
tosca_definitions_version: tosca-1.3
namespace: com.cloudprovider/storage-1.0
...
2) These profiles must be "made available" for the parser, via some kind of on-boarding. It could be implicit or explicit, user-configured or hardcoded. TOSCA itself doesn't have to concern itself with the details, it's up to the product itself and its implementation. For example, they can be stored in a database, a known location on the filesystem, compiled into the executable, etc. The important aspect is that this on-boarding would read that "namespace:" name and register it as the identifier/alias for the profile.
3) Users would specify that name as the "file:" in "imports:". Example for both short and long notations:
imports:
- com.cloudprovider/storage-1.0
- file: org.oasis-open/simple-1.3
 namespace_prefix: simple
We would need to decide whether the parser would first attempt to lookup the identifier or first attempt to read it as a relative URL. The advantage of the latter approach is that it can allow users to override profiles without changing the service template. E.g., providing a patched version of "com.cloudprovider/storage-1.0" as a YAML file within a CSAR.