Christopher Spottiswoode comments from a Metaset/MACK point of view
(Martin Fowler, Analysis Patterns and Business Objects):
(Please first read my Introduction to these comments on your papers.)
To start with a minor comment possibly of some historical value: your "small example" of an analysis pattern, which you called the "measurement pattern", was common currency at the latest by 1970 (At least it was being followed then at Rupert International (where I worked [3(firstly)]), in a so-called "Code Master" facility).
It had some advantages in those days of rather rigid file management, but the kind of flexibility it offers is nowadays quite easily managed using separate fields in point-and-click metadata-based systems (Okay, sometimes less easily than at other times...). Certainly, Metaset will most happily accommodate the "more complex patterns" that you cite, as well as many that your paper didn’t need to get around to.
Of more importance in your story is the part opening with these sentences: "So what are the differences and similarities between analysis patterns and business objects. The key difference to me is that Business Objects are prescriptive while patterns are suggestive."
With respect, it seems to me that your conception of a Business Object is rather too rigid! Of course, one must blame current technology for at least part of that, as proven by the well recognized "fragile baseclass problem". With MACK, on the other hand (I must be getting rather boringly predictable...), there is no such problem.
"But," you might well object, "one wants some rigidity for interoperability, e.g. as in EDI (or the next generation thereof, more fully implementing electronic trading and other synergetic value-creation), or in order to build on the next version from the original developer." To which the response is easy: Yes, but that is then the minimum rigidity that needs to exist. None should be imposed for technological reasons. And analogous rigidities or prescriptiveness might also be sought in the analysis pattern domain (where we would in addition be mindful of the growing integration between A&D and operation in an ever more dynamic and demand-driven world – as indeed was already implicit in the "IDIOM" name itself - Interpretable Design for Integrated Operation and Management - that I trademarked in 1976 (^Find the references to that name in the faq)).
In MACK, both analysis patterns and business objects are implemented as typologies, each in its own way in its sphere of applicability . Business objects/typologies apply to business entities, while analysis patterns/typologies apply to meta- or business model entities.
The uniformity of approach is part of the simplicity of the architecture, and caters for the gradations between business objects and analysis patterns. Differences in expected features are possible analogously to the way in which one programming language can be used without undue restriction for many different purposes.
You might well wonder how I can equate an analysis pattern, which is typically multi-object or orthogonal to objects, with a Business Object in the singular?
In MACK the convergence comes from both sides: a Business Object becomes a typology, which is always multi-object. As I said in my paper (under the "difficult questions" heading):
"[MACK’s] visibility is in partial conflict with the precepts of classical encapsulation, with its usual "complexity-hiding" claims. Compared with MACK the latter are an oversimplification of application decomposition: objects are not islands, as the generalized object model reminds us."
That accords with this extract from my quotation  from Grady Booch on the OMG’s "World Guide to Object Technology" CD: "no class is an island. ... classes collaborate." See also [Ralph].
If analysis patterns might seem orthogonal to objects, then one is still far from integrating upper- and lower-CASE (See also the "IDIOM" reference above).
On the whole though, yes, you are right: the whole field of "analysis patterns" must be far more extensively explored! And such explorers will be greatly assisted by a MACK-realization such as Metaset, and will then be able to report back and share most usefully in terms of MACK typologies.
See also [Paul] re his "business theme" concept.