Lance Lamboy wrote:

....
I checked my copy of oocalc. (I don't use M$ products.) Much to my
chagrin it exhibited the same Excel bug.

Historically speaking, I wouldn't put the blame on Microsoft. You can
download a working copy of the original release of VisiCalc from
http://www.bricklin.com/history/vcexecutable.htm
and verify that it worked the same way. I presume that all subsequent
versions of VisiCalc used the same order of operator precedence to avoid
breaking existing applications. I do not have access to a version of
Lotus, but I presume that they utilized the same order of operator
precedence to make it easier for people to switch from VisiCalc to
Lotus. MS probably adopted the same design decision for the same
reason, when they competed with Lotus (just as they preserved the Lotus
mistake of considering 1900 to be a leap year).

The 1900 Leap Year is clearly wrong, but it would have created far more
problems if dates did not import correctly from Lotus spreadsheets, than
to keep existing aps working and warn users that the date system
included a nonexistent date.

However, to call clearly documented operator precedence decisions a
"bug" stretches the definition considerably, since precedence is a just
a convention that attempts to resolve ambiguous expressions. If you are
that concerned about it, then don't write ambiguous expressions -- that
is what parentheses are for.

Jerry