Comment 4 for bug 1327426

APP_ID is up to you. If it doesn't make sense, that's fine. The nice thing about the APP_ID is that it is used with apps and its value also corresponds to what is used in application lifecycle and application isolation (it is the profile name). It might be nice to continue this line of thinking into scopes, but like I said, if it isn't useful, I don't have a problem with not including it.

I'm not sure I understand this statement: "I don't think there is any point in adding <click-install-dir>/lib to LD_LIBRARY_PATH because a scope can't install anything there." Click packaging is quite simple and is simply an archive file to unpack and some metadata (the click manifest and any corresponding files to support its declared click hooks). As such, a click can contain executables, libraries, data files, etc and a click install will simply unpack whatever is in the archive file into the <click install directory>.

As such, I do think PATH and LD_LIBRARY_PATH should be set since scopes do have execute and mmap permissions on things in their install install directory per this rule:
  @{CLICK_DIR}/@{APP_PKGNAME}/@{APP_VERSION}/** mrklix,

Like scopes, apps may not be expected to execute (or even mmap) things from their install directory, but blocking that seems artificially limiting for developers, so we allow it. Adjusting the PATH and LD_LIBRARY_PATH in the way I described makes it so that application developers don't have to jump through hoops or hardcode click install paths in their code.