Personally, it seems like whenever I want to use somethings gender, I usually want it capitalized, while the BYOND versions are all lowercase. Specifically, the statpanel.
"Gender: male" just looks bad, in my opinion. I realize that there are several ways of dealing with it, such as using copytext and uppertext, but do I really want the game to be copying and uppercasing text every single tick of the Stat proc? Or is it really worth creating my own dummy var for it?

I'm suggesting that there be two gender vars, a lowercase one "gender" and an uppercase one "Gender". Anyways, maybe it's too much for such a minor thing, but it can't hurt to put out there.

Where's the sense in this... uh, so it is worth creating a built-in var for it? No, it isn't, at all. It'd be useless for most people, whoever needs it should simply define it on their own, it's simple and there is no problem with it. Implementing such already easily-doable features to built-in DM, more so 'personal' requests would just add feature bloat.

Yes, ~32k like most limits. But note DM strings are automatically cached, so having, say, multiple vars set to an identical string only counts as one string, opposed to numerous copies, since every var just holds a reference to the single cached version (this is also why you can directly compare strings with the == operator).

Of course. Everything is a trade-off. Not having the gender capitalized is unacceptable, copytext() requires a process hit every 8/10ths of a second for every mob in the world, unless you pre-compute the values, which would also require a list. Might as well capitalize the names yourself in the code and use a list to serve them to the mobs without unnecessary overhead.

I like to focus on solutions that fit the context of the problem, not some idealized solution for a perfect project where everything has to be maxed out in efficiency. Your advice is often way overkill, or simply not applicable to the problem at hand. Your recent argument with PiF about for() vs while(1) was a perfect example of fixing what's not broke. You like to do that with everything.

I like to focus on solutions that fit the context of the problem, not some idealized solution for a perfect project where everything has to be maxed out in efficiency.

Is that so? You've just said yourself: "No, sacrifice a list to save processing." On the other hand, I prefer a solution using a simple switch(), which is only a little bit slower but doesn't constantly take up resources from the game on the background.

Your advice is often way overkill, or simply not applicable to the problem at hand.

That's right, insisting to take resources permanently, even when the code could only actually be used seldom, just to save some very short extra processing time is definitely not overkill, ho ho.

Your recent argument with PiF about for() vs while(1) was a perfect example of fixing what's not broke.

If I'm correct in identifying what you're referring to, that wasn't an argument. What was broke, or more accurately wrong was something Pop said, so I (and Hobnob as well) promptly corrected it. I know you're against correcting things, but oh well.