I'm not a member of your forum, but for me the answer is sample libraries all the way. I like to tweak, and I like to feel a certain sense of control over the samples I have - eg knowing that I can export them into different samplers, combine them with other libraries to make my own custom sets etc. I also hate dongles and hate having the feeling that my investment might be dependent on something as transitory as a company and their licensing scheme, worrying about how many installs I have left and whether I'll need to start firing off emails to ask for another one . . .
I have your Rhodes and Wurly in both Giga and Kontakt format, and use them constantly in the studio and in my live rig. Great stuff. I don't mind paying good money for such quality, but once I have it, I expect to effectively "own" it. (OK, I know that I don't really, yada yada, but you get my drift...)
I'm not so worried about tweaking, but I'm right there with OuchThatHurts on the issue of copy protection. Just managing licenses for my DAW, Giga and NI Komplete is already enough for me. It's not too laborious, but the worry of possibly being left unable to use my sounds puts my blood pressure up. If that were the case for every library as well I don't know that I would cope.
Also there's the issue of running separate engines. I'm sure it must use more overhead to start up a completely new plug-in, as opposed to just putting one more set of samples into a sampler that's running anyway. As someone on a limited set-up this is quite an issue - I spend enough time bouncing as it is.
I don't mind stuff that comes with a player, (such as GPO) so long as there is the option to just use the samples.
Libraries would help advance the medium more. If library developers would use 1/2 the features that have been added to GigaStudio since 3.0, instruments would be more powerful than they are today. Instead of reinventing the wheel, USE THE TECHNOLOGY THAT THESE COMPANIES ARE PRODUCING, and put more product on the shelves at a lower cost...build you catalogs.
Sample Libraries are a quantity business. In any royalty-based business, the size and scope of the catalog is everything. Keeping a fresh and expanding catalog is the key to succeeding.
But in full answer to the question, BOTH. The problem I see is that money is being left on the table. We end users have radically different needs from one another at times. Some of us really love our samplers. Some of us don't care. Some like Virtual Instruments. Don't let one choice exclude others.
At the same time: if we do sample libs too - of same content... we will not get the advantage of only having to develop for 1 format - which is a big problem.
Wouldn't you have to do that anyway, due to the fact that you would need VST(PC), VST(MAC), AU, RTAS(PC) and RTAS)MAC in order to keep your target purchaser in as wide as possible a group?
My experiences as a user are as follows:
Gigastudio; rock solid, never crashes, but has a memory limit so number of loaded samples is not much more than 1GB.
Kontakt2; extremely buggy and almost unusable, interface more confusing than GS and finding the required sample is not always easy (or even accurate). Loads more samples than GS, but is allegedly not as efficient. I don't have the same libraries for both so I can't say.
EW Kompakt player; very stable, but limited in options compared with K2 or GS. Also has less MIDI tracks per instance. However, I've only ever had a couple of crashes.
Spectrasonics; all instruments that I have are rock solid and never crash. The interface is perfect for the application, and I wouldn't want to "run" them from any other sampler.
Vienna VI; I've only been working with them for a couple of months, but so far they are rock solid. I'm loading 2.8GB of samples (on PC) and have yet to experience a crash, except when overloading in the early stages. I also find that the sample loading is more efficient than GS (and they are 24bit samples). The interface is better than any other sampler for doing orchestral music (as one would expect), not yet Multitimbral (which is a shame and a pity for a couple of reasons), but I wouldn't want to go back to using GS for the VSL library.