Windlight
Havok 4
Mono
group Tools
Avatar
etc, etc....

There's so much on their plate already, that there just isn't room for some things. This is intended for those where it's obvious, not ambigous

Way of saying "I would like this" but I am aware that it is technically difficult or might cause too much breakage or that there are many many more important things ahead of it.

<joke>Save Warkirby the trouble of pointing it out in comments :-P </joke>

Added SVC-263

The definition of the Meta as it stands at the time I post this: "Those which would be nice, but for some reason, are unlikely to be implemented reasonably soon, if ever." is pretty non-inflamitory as far as I can see. YMMV. I don't think it is wrong to say "Nice idea, but..." and I would rather that than have such items shut down.

Sometimes I think it is good to indicate long-term wishes, if only because sometimes even if they are not going to be implemented any time soon, they can contribute to features that ARE being implemented in the short-term having hooks/openness/etc. left in them so that other ideas are at least not pre-broken (assuming leaving such hooks doesn't add to complexity, of course - I wouldn't advocate making an interface more complex 'just in case', but making one more generic, yes).

Other other hand, it is not always easy to judge what is/isn't possible form outside LL's simulator code base. For example: I have heard from a source that cannot be verified - so take this with a mega-prim-sized grain of salt - that the internal representation of prims in the grid servers bares virtually no resemblance to the shapes/attributes presented in the tools pallet (there is a translation layer). So assuming this, various VWR-3852 items may be either much harder to implement than one might think, or trivial; and no-one outside the relevant-area programmers at LL would know which.

Another example: re: SVC-263 (sorry to harp on about my own FRs but they are what I am most familiar with . I was recently in a position to play with the production SL client outside of what is normally possible in SL (due to breakage on the OpenGrid Server system) and found that a good chunk of the client is quite happy with rendering negative altitude (even terrain texture height fields in the region controls support it). The issues were server-side: predominantly the OSG physics engine was borking seriously, though I can't speak for Havoc 1 (or 4) so support of negative altitude is somewhat in the client already, whether by design (possibly LL wants to go this way already one day) or as a matter-of-course (the libraries they use support such things out-of-the-box and there was no reason to change them not to). That doesn't mean that SVC-263 is necessarily possible without huge changes, but it could just as likely be a (coding-wise) trivial change. Without a familiarity with SL-Grid code (probably more familiarity than even any single LL programmer has in this case) who can tell?

deBono arguing style intrinsic to my upbringing - you throw in ALL ideas regardless of whether they support you or not, then look back at the lot, rather than the taking-sides-from-the-outset approach more traditional to Western thinking culture