That table came from a static solution itself - I copy-pasted every one of
those entries (and many more which didn't get in) - into an excel file
first, which I use for myself. Pasting the most relevant parts of that
file to a wiki format was my main contribute to the floss manual.
But it's wrong, the content table should be dynamical just like the build
process is in each version. The thing is, I don't know how to work with
scripts, and there was no one else who did this. So the answer is very
easy, someone else make it better. I've done as much as I could, following
the editorial criteria of that time.
A dynamic list would be a very good resource for pd-ext, as very few
people know about externals outside of pd-van, gem and zexy. Be it in a
patch, a web page, the auto-completion plugin, or any other form. It
should only be in a form where it could be easily interacted with while
patching in Pd.
Having a static table of objects that informs the user what's included
in thecurrently shifting target that is Pd-extended is the wrong approach. My
solution would be to delete the entire table, but maybe someone else has
a better, less drastic idea.
-Jonathan