That's right.  The only part that imposes a limit on the message size is the simple message assembly mechanism for sending lists to Pd.  Lists that are created elsewhere have no such limitation.
 

Hmm.  I'm reluctant to add a call for changing the array size because this entire message assembly API is really just there for the purpose of simplifying the creation of language bindings.  Any additional complexity would make it even harder to justify.  So far I've felt that it was justified because it seemed good enough and I believe its simplicity has helped the adoption of libpd.  If it turns out to be too limiting (and this thread suggests that that may be the case), then I'll have to bite the bullet, deprecate this approach, and write the manual type conversions for Java and other languages that I'd been trying to avoid.  The good news is that the latest version of libpd already comes with a new pair of message passing functions that are not limited in this way.

The current limit was chosen in the following highly scientific fashion:  I tried to think of the longest list I might want to send as a message, and the biggest thing I could realistically think of was an OpenGL transformation, i.e. 4x4 = 16 numbers.  Then I doubled that count and hoped that that would be enough for everybody.

Maybe we can have a poll and come up with a better estimate.  Here are a few questions:

1. What sort of use case for long list messages to you have in mind?
2. Exactly how long would you need the list to be?
3. Is this really a use case for list messages or would it make more sense to write to an array instead?

If we converge to a reasonable number, that'll be the new limit.  Otherwise, the entire approach may have to go.

That's right, there's no intrinsic limitation in the functions.  With the new approach, you're responsible for creating the t_atom arrays that you're sending; if you can create it, then the new functions can send it.
Cheers,
     Peter