>For instance, KenL's response indicates emphatically that MS would basically ignore any such list, meaning that it would still be necessary for the originator to send a (duplicate) request through formal MS channels. Is that acceptable?

I think this is not a problem.
KenL says this in order dissuade the community to make it.
If a list of Bugs, "managed well", comes published in a public site, and the bugs do not come send to the MS, MS does not have alternatives, will have to use this list.

>Similarly, it would take some time before the list held sufficient content (number of items) as to really be useful. Is that OK? Would people still be motivated to fill it and to use it?

Many people.

>So, assuming in the worst case that a BUG List on the UT would be available but only used by UT members for viewing, monitoring, commenting and obtaining workarounds to such potential bugs, would it still be useful enough to have?

Today some serious information on the bags of VFP does not exist.
Therefore, only UT members uses this list, but any developer that it will know the existence of this list will become a UT member.

*****************

The true problem:
"managed well" is the magic words.

This list need central management, not distribuite, it will not never work if it will be left to the independent management of the members ( see Wiki example ).

This list needs of two database:
- public where all bring back problems or the presumed ones bugs find to you; this can be managed like one category of a public forum;
- an other database ( central management ), is that one published, read only where the bugs are brought back confirmed or much probable. (This would have to be to payment)

If the second not is, the thing dead after little time.

Necessary the minimal information are:

- date of pubblication
- VFP versions where it appears
- description of the bug.

not essential
- code of example
- workarounds.

This must be opened to additional revision, not to overwrite revision ( MS style ).

In the improbable hypothesis that the MS supplies support,
the MS must, necessarily, supply this information:

- VFP version where the correction of the BUG is forecasts.

After 90gg from the pubblicazion of the bug, if the MS not filler forecasts, the bug is not solvable, and the developers must to resign oneself to find one road alternative of program coding.

Fabio