$ans = something ? 'true' : 'false' is ... a single sentence. Each sentence in the deeds should be easy to understand.

Agreed (with caveats*). So, then the question becomes: do you (we; perl programmers in general) find the ternary operator -- used correctly -- easy to understand?

Given that I found multiple uses of the ternary operator in each of 4 (out of 5 chosen at random) of your distributions that I looked into, I'd assume that you do. So do I. And so do (on the basis of anecdotal evidence) a substantive majority of Perl programmers.

(*)Caveats: Deeds, like many other legal documents, contain many terms and 'set phrases' that do not crop up in any other circumstance. A few examples drawn from the deeds of my house:

Any easement or quasi easement right or privilege whatsoever over or against the Transferor's adjoining or adjacent property or any part or parts thereof other than any rights herebye granted

(but without prejudice to the generality of the foregoing)

not to use or occupy any such dwellinghouses for any purpose other than the occupation of each dwellinghouse by one family at one time.

The phrases, despite their wordiness, are actually shorthand, that convey far more extensive and more precisely defined meaning than is apparent from the sum of their words. That meaning is conveyed not by their wording, but rather by the years -- in some cases, centuries -- of use and reuse, and of trial and retrial in the courts; and so are proven to constitute their precise meaning through case law. (Update: Think idioms.)

That is nothing more than an (I hope, interesting) aside, but it makes a specific case for the general point that technical documents, whatever their type, will contain nomenclature the meaning of which will not be immediately (at a glance), obvious to those unfamiliar with it.

To the unknowing outsider or beginner in the field, these nomenclatures may seem complex and unclear, but they are usually quite the opposite once you understand their purpose. And understanding their purpose is nothing more than a matter of becoming familiar with them, and practice. Ie. You have to learn them.

These nomenclatures crop up in every professional field; but only in programming is there a generally pervading notion that they should be avoided to lessen the learning curve for beginners and those less willing to extend themselves.

Lawyers are required to do 4(?) years of advanced, specialist education before they can practice; and then accumulate many more years of both learning and experience before they can progress to barrister; more years still before they can become QCs; and more after that before becoming judges.

There is similar requirement for both practical experience and ongoing learning for doctors; engineers; surveyors; physicists; chemists etc.

Of the professions, only programmers can start to practice after a 12-week course in some archaic teaching language at college; and only programmers seem happy to devalue their skills and learning, by advocating the output of their years of experience should "understandable at a glance" by any oik that knows how to load the source code into an editor to view it.