This yaml (taken from the bug description) isn't valid snappy yaml according to meta.md:
binaries:
 - name: bin/document_viewer
   description: "ubuntu core app document viewer"
   start: ./bin/document_viewer
   security-template: unconfined

Apart from the '_' in the name filed, it is using 'start' with 'binaries'. 'services' already supports '_' for the binary name specified in the 'start' field. Eg, this is valid:
services:
 - name: document-viewer
   description: "ubuntu core app document viewer"
   start: ./bin/document_viewer
   security-template: unconfined

For binaries, we also currently support '_' for the binary specified in the 'exec' field. Eg, this is also valid:
binaries: 
- name: document-viewer
   description: "ubuntu core app document viewer"
   exec: ./bin/document_viewer
   security-template: unconfined

However, because 'exec' in 'binaries' is considered optional, there is the problem area:
name: foo
version: 1.0
binaries: 
- name: ./bin/document_viewer
   description: "ubuntu core app document viewer"
   security-template: unconfined

With this yaml, snappy transposes './bin/document_viewer' to 'document_viewer' when creating the APP_ID (https://wiki.ubuntu.com/AppStore/Interfaces/ApplicationId). The APP_ID uses '_' as a delimiter, and the APP_ID is used to differentiate between 'services' and 'binaries' shipped within a snap for the systemd service definitions, cli binaries and apparmor profiles. As mentioned, the review tools will catch this (though they are currently disabled-- they're caught up now and could be re-enabled).

Historically (ie Touch), there was a clear distinction between package names and binary executable names. It was decided that '_' would not be supported in package names, app names and versions, because, like Mark said, it was considered poor taste and because it wasn't an allowed character in Debian versioning schemes anyway. '_' was then agreed upon as the delimiter for the APP_ID in part because it is cli-friendly (no shell-escapes needed). Fast forward to today on snappy and the '_' is still the delimiter for the APP_ID and this all works fine for 'services' yaml and 'binaries' yaml that specifies 'exec'. With 'binaries' without 'exec' though, the binary executable is being used as the 'app name' part of the APP_ID and as we've seen, the transposition that snappy does isn't accounting for the '_' in the 'name' field of 'binaries' that don't specify 'exec'.

The easiest and least regression-prone fix is to make snappy build fail/review tools error when specifying '_' in the name field when not using exec, but to then make a helpful suggestion to either use 'exec' to specify the binary or rename the binary. If after making this change it is felt that it is not enough, we can explore other options. Eg, snappy could be made to transpose the '_' of the name field into something else which is doable but more regression-prone since anything parsing the package.yaml to obtain the APP_ID would have to do the same transposition. It is also possible to change the definition of the APP_ID, but this is very regression-prone when considering Ubuntu Personal (where the APP_ID is used by various trusted helpers, in application lifecycle, etc).

I suggest we 
I suggest adjusting snappy build/the review tools for now so people