Some examples and suggestions:

1. "I have been using the above hint with the trial of Omnifocus. I finally bought Omnifocus from the Mac App Store and this hint no longer works. Any ideas on how I can re-enable it? The hint was so useful and I became so used to it."
   http://forums.omnigroup.com/showpost...89&postcount=5
2. An old technical tip from the CEO. Works well for vanilla copies, (as long as you use whpalmer4's correction of Ken's typo :-) Mac App Store copies ? Bupkis - just an error message about a missing database.
   http://forums.omnigroup.com/showthre...1107#post41107
3. A recent technical tip (June 1 2011) tweeted by the CEO. (A real value of Omni products ... how many CEOs take the time to do this ?) Works for vanilla copies. Mac App Store copies ? Not even bupkes - fails with no error message ...
   http://twitter.com/#!/kcase/status/76012475602051073
4. Integration of OmniFocus with Devonthink. The scripts for opening project notes and folders in DT2 work with vanilla copies. App Store copies ? "Missing database".
   (I haven't worked out a bullet-proof* way of modifying them, and as a simple user just sharing stuff I make for myself, it's kind of hard to justify the additional time to research a better approach and retrospectively work through all my code to suddenly make it 'bilingual' ...)

And so on and so on... any command line tips involving defaults write (as in Ken's recent tweet) or sqlite3 (as in Ken's first tip above) or any other reference in a command line or an applescript to a bundle identifier string - all of these divide the community of OF users into two different tiers of citizenship - those who inherit a wealth of tips and scripts, and those who unwittingly inherit a legacy of puzzlement and exclusion. To quote again: "I finally bought Omnifocus from the Mac App Store and this hint no longer works ..."

But no mention of any of this in Omni's advice to those who are deciding whether to buy through the Mac App Store, and no technical guidelines either for those who have bought this way, or for those who are willing to offer first aid to MAS buyers in the field.

In fact, while I am sure that Omni gave careful thought to the engineering perspective, I am not quite so sure that they gave as much thought to (or have even yet fully digested) what it really brings to users.
In example 1 above, derekr appears to have been caught off-balance, and in his June 1 tweet, Ken Case does not appear to be conscious that his tip will fail for Mac App Store customers.

At the time of writing this, the Mac App Store FAQ for OmniFocus contains no mention, from Omni, of these issues, and no related technical advice ...

Suggestions:

1. Let prospective buyers know (even if only on ethical grounds :-) that App Store copies bring limitations (see the examples above) which other copies don't.
2. Now that the network fragmentation of Genesis 11 5:8 has occurred, and is probably irreversible, at least ensure that all new technical advice from Omni is 'bilingual' ...
   (monolingualism from other users/scripters is probably just tough)
3. Publish general guidelines for adapting command lines and scripts. (What, for example, is the best way of detecting from the command line, when the app is not running, which variant/allele is installed ? )
4. Generally give more weight to user experience and network externalities (in the balance with engineering internalities). What makes life easier for a developer may not make life easier for a customer.
5. and particularly avoid proliferating bundle identifiers - they fragment the exchange of technical advice and scripts, and this diminishes the value proposition for everybody.

--