Is password strength exclusively a function of character set size multiplied by password length-in-characters?

You already have a couple good answers to your actual question, I'm going to answer the question you didn't ask and give you the correct answer:

You need a secrets manager!

Now I may have misunderstood you a bit, but you talk about passing along context from one system to another, and it sounds like when you do this "context" may include passwords, causing issues when different systems need to escape special characters in different ways. Sure, you could remove special characters and increase length to maintain entropy but based on your question I suspect the following steps will help a lot more in the long run:

1. Employ a secrets manager to store all of these "passwords"
2. Update your build systems to get "passwords" out of the secrets service directly. You should very rarely have to pass secrets from one service to another.
3. Make sure that all services can only access the secrets that it actually needs from the secrets server
4. Stop using passwords for server-to-server calls!

This will help substantially with your immediate issues and will also greatly improve your security posture. So this is one of those cases where the "right" thing from a security perspective is also the "easy" thing (in the long run). Trust me, although there will obviously be some work needed to make this happen, it will be far easier to manage all of this with a proper secret manager. It will also allow you to more easily rotate your secrets when needed, and will keep them out of a thousand different configuration pages.

Also, why do you call these "passwords"? I don't normally call secrets that you use to authenticate in a server-to-server context "passwords". This isn't necessarily just a matter of naming either. Server-to-server access credentials usually have options for things like rotation, expiration (if needed), permissions, and they are (often) base64 encoded so that they can easily travel between systems without these sorts of issues. As a result I suspect that you may have a more fundamental issue hiding in the background here.

Is password strength exclusively a function of character set size multiplied by password length? Well, to be precise... not exactly.

Technically, entropy alone is not enough to guarantee you have a strong password. Strong passwords are supposed to be generated with enough entropy, and also look random enough to defeat dictionary-based attacks, or other related attacks. Also, technically, if a password with enough entropy and that looks random enough has been leaked and can be found in leaked databases, then it's not strong enough anymore.

What I mean in practice is that a 8-char randomly generated password might look like 49thS1bp, or might look like 123abccc. The second password though, unfortunately, by chance, contains patterns that make it easier to attack. As another example, by chance, you might end up generating a passphrase like correct horse battery staple, or orange banana banana orange, and those will not be considered safe enough (by the way, correct-horse-battery-staple has also been found in leaked databases). Also, consider what would happen if you used a custom word-list for generating your passphrases, so instead of the typical English-based word-list for diceware you would be using a list of words in your own native language, some other foreign languages you know, and maybe some local slang. The entropy will be the same (same size of the list, same length of the passphrase, etc.) but strength will be increased, because dictionary attacks will be less likely to succeed on average.

In your case, if the method of generating and checking the passwords is always the same, then you can just use the formula C^N for estimating your password strength, where C is the alphabet size and N the length of the password, exactly like you said. Also, if C and N are large enough, you can even forget about checking for patterns or checking in leaked databases, because those weak points will become less likely.

To sum up, even with perfect randomness, C^N technically defines the password entropy, not necessarily the strength. However, if C and N are large enough, this distinction becomes less important.

Update: Oops, I didn't actually answer the question asked. Instead I answered based only on the title. So here is a second shot.

Focusing on

if we have been generating "sufficiently strong" passwords of length x from the 95 printable ASCII characters, and we reduce the character set to the 62 lowercase, uppercase, and numeric ASCII characters, will there be any loss of password security whatsoever by constructing passwords of length y, where 62^y >= 95^x?

No, there will not be any loss of strength. Assuming that you are selecting from the character sets uniformly (or close enough to uniformly) then the magnitudes of 62^y and 95^x are exactly what you need to be looking at.

Why this is even a question

Many people, including some in the security community, have come to the mistaken belief that special characters make passwords stronger merely by being special characters. If you hear over decades that you should add special characters to a password to make a good password it is natural to assume that there is something special about these.

But back when that was good advice, it was good advice for different reasons. It changed people's habits in creating human generated passwords. It was a psychological trick to drive toward a flatter distribution of human password choice. As such the real benefit of those requirements was unclear both to the users and to the people setting the requirements. And so people concluded that special characters automatically make passwords stronger.

But when we have passwords being generated by systems that produce a uniform distribution to start with (so not human created), the math is simple, and 62^y >= 95^x is all you need to consider.

---

Original answer (which was not to the question asked)

Password strength is a function of the system which generated it. Let me quote from something I wrote nine years ago on the matter.

The strength of a password creation system is not how many letters, digits, and symbols you end up with, but how many ways you could get a different result using the same system. [...]

I can’t over-emphasize the point that we need to look at the system instead of at a single output of the system. Let me illustrate this with a ridiculous example. The passwords F9GndpVkfB44VdvwfUgTxGH7A8t and rE67AjbDCUotaju9H49sMFgYszA each look like extremely strong passwords. Based on their lengths and the use of upper and lower case and digits, any password strength testing system would say that these are extremely strong passwords. But suppose that the system by which these were generated was the following: Flip a coin. If it comes up heads use F9GndpVkfB44VdvwfUgTxGH7A8t, and if it comes up tails use rE67AjbDCUotaju9H49sMFgYszA.

That system produces only two outcomes. And even though the passwords look strong, passwords generated by that system are extremely weak. Of course nobody would recommend a system that only produced two outcomes, but people do recommend systems that produce a far more limited number of outcomes than one might think by inspecting an individual result of the system. This is because humans are far more predictable than we like to believe.

That is an extreme and contrived example, but I hope that it helps make the point. The statistical properties of the set of possible passwords a system can generate are where the strength (or weakness) come from.

Provided that the password is really random, yes. The relation you propose holds (a humorous but rigorous calculation is presented in the XKCD comic link below):

passwords of length y, where 62^y >= 95^x

But I notice that you opened the question with "which we do almost exclusively programmatically (all generation is random-enough)". "Almost" and "enough" are two telltales that the generation might not, in actuality, be equivalent.

Awkward as it may be, it might be better to strengthen those points in the workflow where passwords enter scripts and metacharacters might get interpreted. This, in my experience, can be readily done by preparing a set of evil passwords containing the various escapes, and seeing where the workflow breaks. It will make for some heart-aching afternoons, but in the end the results might be better:

• you needn't worry that a password is inserted that is "not random enough"
• you needn't worry if an old password or other unpredictable event slips a shell metacharacter in the workflow
• you needn't defend your choice: having a larger y might be criticized by some users who find it inconvenient.
• you needn't dread regulation or customer agreements. This has happened to me twice - we had to certify that our security policies complied, i.e. were "as strong or stronger", with those of a customer. Problem here is that the agreement is managed by lawyers and inspectors that are either unwilling or unable to comprehend the "if 62^y >= 95^x the password is just as safe" argument, and will accept $af3! but reject correct horse battery staple because it doesn't let them strike out the proper boxes in their checklist.