I am calm, I just sound like that sometimes.
I dislike idea of having too much clonks as well, imho 2 to 4 clonks is the best option, but not having more than 1 clonk? In races and fast-paced melees - sure.

As for AI I've got an idea, but no idea how hard it would be to implement it.
Basically you do this in steps at beggining of the game, and just update it later when terrain is modified(or will it be unnecesary?):
1) Divide map into sectors(maybe 256x256?)
2) Trace all of the terrain edges(liquids would be ommited for now)
3) Convert traced edges into fragments, optimize their amount of vertices and classify them as:
-Climbing(wall)
-Walking(floor)
-Scaling(ceiling)
4) Place a lot of waypoints on every 'path'
5) Generate paths from as many waypoints to as many waypoints as possible(including points in nearby sectors):
-Automatical connection of points of single path
-Fall path(for jumping from ceiling/wall)
-Jump path(for jumping from floor onto ceiling/wall)
6) Place a large grid of points in terrain, and then:
-Destroy points completly covered in non-diggable terrain
-Move a bit points at edge of non-diggable terrain
-Generate 'Dig' paths through diggable terrain, usually from one 'wall' or 'floor' edge to 'wall' or 'ceiling'(but also from floor to floor, if needed)
7)Destroy unused points, merge points close to each other and cull 'walk', 'climb' and 'scale' waypoints unused in digging in favor of longer single path lines
8)Check for lines/points in two sectors at once(ie.: Point perfectly at edge, line with one point in one sector and one in other) and mark them as 'portals', calculate series of waypoints from each sector entrance to each other(if possible and not blocked)

And then while running game do following:
1)In case of terrain being modified:
-try to reconnect all broken paths(with either jumping, falling and then climbing or something else if needed)
-Remove dig points, which are now on surface(or convert them into 'fall' or other points)
-Calculate new edges, points and paths in modified area(and around)
2)Give each point priority:
-Normally a path fragment gets priority based on time needed to traverse it, but there are exceptions:
-Points close to your base/territory(between your buildings) gets higher priority as it's 'safe'
-Points close to a deadly material(lava,acid,etc.) get 1/2 of priority
-Depending on current AI mode there are + or - points for paths near enemy units and buildings
-Dig paths have lowest priority, both to minimize travel time and prevent too much of waypoints updates...
3) And then use some standard, high performance algorithm for pathfinding

I guess it'd be quite hard to implement, and am not sure how good it would be, but I had this idea floating in my head for a while, so I couldn't not write it in the end :>

> [...] to have NPC clonks on your team which do menial tasks [...] This would likely require a better pathfinding system [...] and possibly some NPC only exploits [...]

That's actually a nice idea, which might be worth a separate discussion.
They might be associated with (spawned in) either the home base or the production buildings, perform some of the micromanagement tasks, and e.g. get respawned automatically after some time if killed (so natural disasters or other players might kill them to hurt productivity but without distracting a player too much from his other tasks). It would give clonk settlements a lot more life, somehow I have to think of settlers2.. :)

A lorry full of gold is almost too heavy for one Clonk and that's the clonkish realism I like.

>perhaps recording the player's movement that he took to go from point A to B and replicating it?

Yeah, that's a beginning.

Well, I always walked with few clonks to speed up construction, and as for my arguments:

>--ruining spirit of clonk

You always had multiple clonks in clonk, so it would be quite extreme change, and there are already things done and/or planned that change the game a lot, I think we shouldn't really go that far, so imho doing things like this, which are not 100% sure to do good is not a good idea

>--ruining settlement scenarios

Single-clonk building, hauling, no guards possible, no research/production/etc in background and so on...

>--ruining melee scenarios

That would only be for particular scenarios, in general it's not nice to go seeking for enemy base and while after get an alert that your base is under attack and being unable to protect it...

Yeah, the beloved rescue team stories. :)

I'm somewhat torn about that. Having to (manually) rescue your clonk is good for the following reasons: It 'punishes' you for being sloppy (too careless while walking around cliffs, not building your tunnels flood-proof, etc), and it makes a clonk's life feel 'valuable'. On the other hand, rescue missions sometimes become tedious. Your productivity is down to zero while you rescue your clonk and it usually takes some time and effort. Additionally, the rescue missions are pretty unsafe as well (as you said). So, losing your rescue clonk, too, and then the next one, and so on, isn't too much fun either. Altogether, rescue missions can be a funny gameplay element, but saving one clonk by throwing more clonks at the situation doesn't feel entirely right either.

> "pay 20 gold and respawn at next base" ... When your other Clonk had equipment, you still get to rescue that

Hmm. It sounds like it's worth trying. I have two throughts about that: First, just paying some gold seems a little 'cheaty' to me, to be honest. This way, something bad happening to your clonk suddenly becomes a complete non-issue: Just restart at your base, problem solved. Second, on the other hand, the problem is moved from 'clonk lost' to 'equipment lost', so the arguments above apply again, and 'equipment rescue missions' might become tedious. This could balance one another well or not.

Technically, the clonk can now carry 7(!) items but only the first two are shown in the HUD and only into the first two items are automatically collected.

>Isn't "we save 3 seldom-used keys, and quite a lot of overhead interface space" argument enough?

No it isn't. Currently we use 1 key, IIRC: "Next crew member". Though, probably most players will click in the hud anyway.

>For example when thinking about relaunches

True, the respawn idea is not too compatible with having more than one clonk. Probably because you suggested that feature to replace having several clonks.

Currently, to go against the problem of clonks in a trap, the last clonk is dead and one is eliminated etc. the possibility to always buy another clonk in the base from the HUD could be implemented - regardless if there is one clonk left on your team or not. (e.g. a button that is shown left or right of the clonks-display on the top which shows a clonk and coins.) This clonk will respawn in the building that has been marked as the players base.

Edit:
Don't get me wrong. I don't want to actively argue against limiting the maximum number of clonks of a player to one either in standard scenarios or even in the engine. It's just like I said: I don't see any convincing arguments yet that clearly speak for limiting the player and the scenario developer in such a strong way to go through the hassle of implementing all this and no other possible solution. The problems you posed as the definite reasons for limiting the number of clonks to one do not have to be solved like this, there are other solutions possible. This discussion started in the wrong way, first there was the suggestion to limit the number of clonks to one and then began the search for reasons why it would be better.