i think the main problem flext and readanysf~ might be the latter's dependance on a large number of external libraries, although i don't know which kind of clash that could cause.
actually, the biggest problem for me at the moment is the object wrapping that exists in flext. now, whenever you delete() a C++ object using a flext version greater than 4.5, PD will crash hard. There is a switch in flext, but expecting users to turn this off is a bit too much.
what are the advantages of such an approach ?
or rather, what are the big disadvantages of using flext ?
well, initially, I thought it would be great to easily compile pd externals for MAX. but, the chances of me ever getting around to taking the time to sit in front of a macintosh or windows machine and compiling an external are now becoming more and more slim. and, if you are writing in C++ anyway, then you probably have your objects in a decent enough form to just switch from the pd api to the max api.
i do not use it myself (since Gem has its own C++ framework and my rest is done in C), so my ideas of flext might be clouded. the only reason to not use it that is see, is an additional dependency. isn't it possible to link statically against flext, so the dependency would only exist at compile time ?
you could link statically, but then it adds some uneeded KB (about 90kb I think) to your external. and if you load 20 of an external, this is a pretty heavy hit.
or is the flext-api highly unstable (so that it is a pain to upgrade from one version of flext to the next ?)
except for the changes from 0.4.5 to 0.4.6, flext has proven to be extremely stable.
and, like frank said, you will probably want flext anyway on your machine to get Thomas's awesome externals.
best -august.