Even if I write scripts for myself? And even if (as a user) I feel like turning off a warning for what others have already written despite your opinion? And even when my verb explains what is happening better than any "approved" verb? Why is it better to not know what is happening by reading the function name as long as it is on some list? I have a command Login-AWS. Guess what it does. If you guessed login to AWS, then I choose the name well. I don't see any approved verb that fits that.

The Powershell developers are not going to be able to think of every action that anyone might ever take for the rest of time. I do agree that the Powershell language team should try to stick to their list, and they can add a verb with any new revision of Powershell if they find it prudent to add a function that does something new, but not every independent private programmer in the world. I do generally try to follow the Powershell suggestion of using a verb and noun, but sometimes I like mine better.

And, that was always a suggestion. This warning message never happened until recently. I know I can use the Import-Module command and disable the warning, but generally I rely on the automatic module importing feature that Powershell introduced long ago. And right now, I don't want my program flow to be interrupted by any nonstandard verb. Why should an option not be created to allow me to turn that off if that is what I want? There are all kinds of options like that already. Why is this issue so special? I usually turn on strict mode, but that is not forced onto everyone.

You are rarely the first person to come up with a concept. When in doubt you can check what other people have done to handle your scenario. VMWare uses Connect-VIServer to "login" to the Vcenter. Cisco uses Connect-UCS and Connect-UCSCentral to connect to their UCS platform. Microsoft uses Connect-AzAccount. I'm beginning to sense a pattern with the names here.

Thanks to these common design patterns I know to look for Connect-X to connect to some service in PowerShell. Anyway, as for an option to disable it, can you try to run this: $PSDefaultParameterValues.Add("Import-Module:DisableNameChecking",$true) and then do an implicit import? I think that might disable the warning for your session.

I don't like verb standardization at all. And I think it would be better to make it a desirable rule rather than a law.

Also known as Separation of mechanism and policy

Should PowerShell be restrictive by default and then users have to relax constraints, or the reverse where you have to harden an installation?

I am sure that PowerShell requiring scripts to be signed by default was a nail in the coffin for many users, but welcomed by IT departments.

Thank you. That helps. I didn't know that was possible. Instead of Powershell auto-importing the "offending module", I still have to add the Import-Module command for any module that has verbs that I want to ignore, which you helped me think of. But, at least I can get where I want to be for repeated use of common modules. So, I think that's a decent work-around.