The Arduino style guide definitely calls for camelCase. Inside the library either is fine, for local and private variables and private functions. I personally prefer underscores, and I'm perfectly happy to accept pull requests with almost any style for internal stuff. Following the style guide is important for the public functions.
Regarding uniformity and consistency across the whole library, I believe there are trade-offs. Again, I want to follow the Arduino style guide. Specifically regarding naming of functions in the effects:
To change what flange does requires a name other than voices and other effects/filters will probably have their own unique function which changes what they do. I think it might be better to have a 'paradigm' such as:
begin, modify, stop (or pause?), end
which applies to the whole library. In each specific effect/filter/etc, modify might require a different number of arguments but its intent/functionality is clear throughout the library.
The Arduino style guide definitely calls for descriptive names using whole English words that are easily understood by intelligent people without a background in programming or audio jargon. It recommends "pick terms that correspond to popular perception of the concept at hand".
So I would say yes to using different names specific to each type of effect. While I personally see the technical beauty in a highly uniform API across the whole library, I believe going to very generic terms that lack description of what the function does is straying too far from the Arduino style.
Where I do want to see uniformity is within certain categories, especially Play and Control. Well, at least for the very basic functions in Control. The reason is not to make the entire library more understandable, but rather to allow more easily substituting one object for another. This interchangeability should allow most sketches that use only the basic Control functions to use a different chip only by changing the object name. We already have SGTL5000 and two flavors of WM8731, and over time several other chips are likely to be added. Of course, most chips like the SGTL5000 are loaded with special features, so sketches that use those features won't be able to switch. On the Control category, I started some work early on to define the common set, but like so many things in the library, it needs more work.
Play objects are the other category where I want to make switch between objects easy. Perhaps someone writes a sketch that does some awesome sound effects playing from internal flash memory. Someone else uses the code in another project, but their sounds are longer. Or maybe the memory ones are 11 kHz to save space and the new project high a high-end sound system and wants full 44 kHz samples. The idea behind standard names in the Play class is to allow that new project to reuse the code, but just store the sounds on a SD card (or perhaps the optional SP flash chip someday). Because the Play functions are the same across objects, the same sketch can be used by just changing the object name.
Hopefully this helps a bit? I know it's a lot of not-so-fun work to mess with code that already works. I really to appreciate every contribution you guys have made and I hope this renaming of stuff isn't too painful. Pretty soon one of the major distributors is going to start selling the audio adaptor and there will be a lot more pressure to get a 1.0 release done, so this really is the last opportunity to rename things for the Arduino style and better consistency.
Edit: plenty of the parts I've written don't quite follow the style guide either, or have inconsistencies. Feel free to mention those; my feelings won't be hurt. My main goal is to make this as usable as possible, with the simplicity and style people expect in Arduino.