role based permission

There's currently no permission required to see/use the editor other than having access to the input format it's assigned to. Why should anonymous users not have the benefit of the editor?

I can give you a possible use case, we have a similar need actually. The specific example is that the only form the anonymous user can use is the registration form. Fields included on this form are provided by content profile.

When a potential new member is to register, we need the form to be as clean and simple as possible, the site's UX guidelines dictate that the form not be "cluttered" with wysiwyg buttons.

The user registration submission is reviewed and after the account is approved and the user is assigned the member role, he can then edit this form with the fields from the registration form and a few new extra fields. At this point we can present him with the wysiwyg buttons so he can make his profile using markup.

We don't block the use of markup on the initial form, we just don't encourage it, to keep things fast and simple.

In order to not modify the module, we currently use a different input filter for anonymous users without wysiwyg and in the approval process we manually change the input filter to one which has the wysiwyg editor enabled. Fortunately this is a low traffic site so its possible, though its hardly ideal.

If the module allowed permissions per role, it would allow us to not have the module show for anonymous users.

Further, the site admins all dislike wysiwyg and it would be helpful if this role never had the editor so that they can easily clean up any messy html.

I think the core issue is that you see the wysiwyg editor as a benefit for all. Sometimes though it represents unneeded complexity which can stymie less sophisticated users for whom a plain text box would be less intimidating.

The proper solution would probably be a per role, per input format system, which could be made an enableable option. The interface could be "input format wysiwyg profiles" so that instead of 1 profile per fomat, you could add profiles to the input format, which would allow selecting which roles that input filter profile is valid for and what behavior it dictates.

As an example for the presented use case, on filtered HTML anonymous users would have no editor, members would have tinyMCE and admins would see bueditor (which is unsupported in this module, but im using it as an example).

Thank you for taking your time to write this!

Yes, I do tend to see the editors as a benefit to most, but I do also understand that for some use cases that's just not true. When users say something like this needs to be changed, I'm knowingly being a bit stubborn on the subject. It's because I'd like to get just the type of response you gave me. It's sometimes very difficult to get a use case that has been this thought through and tested which can be used to motivate the suggested change. Without this, we might change things based on what users think they want, rather than what they actually need, ending up still disappointing the user (or someone with a very similar use case) after the change was made, so we need to change things again.

Back on track...

We do have plans for allowing multiple profiles per input format and which profiles are available to which users may indeed become controllable per role, which would solve most of these issues. Though, the time we've had left to actually work on this has been very limited . :(

To help you out with this specific case, so you'd not have to wait for this to get implemented but still get rid of some of the manual burden for new accounts, I'd like to suggest a few workarounds.

Wysiwyg 7.x-2.1 and 6.x-2.4 have reintroduced support for forcibly disabling WYSIWYG editors via code, by simply adding '#wysiwyg' => FALSE, to a field element. When Wysiwyg sees it, the field is simply ignored.
Perhaps you could use hook_form_alter() to apply that attribute to the fields on the register user form instead of swapping input formats after they're registered?

If that's not an option (say you've already built the site around the format-switching and changing it requires updating hundreds of nodes), perhaps Rules could automate the process of switching formats when a user has been approved? I don't actually know if Rules has an action to do this, but implementing it shouldn't be that hard if you're familiar with Rules.

Btw, If editor profiles are set to allow it, users should also be able to set the default state of the editors (enabled/disabled) on a per-format basis from their user settings. That might make the admins less annoyed. ;)