My $0.02. Warning, opinion spewage below.
/Soapbox on
Venom doesn't affect conspects: is this too artificial?
I would say yes. I changed my little learning bot to use info shots to fix prey instead of venom after the discussion above and quickly found they were fixing each other occasionally with all those fixing info shots flying around until I added the .fixed checking/resetting gene. So, I'm already coding my bots against a sort of anti-venom from conspecs. I'd (perhaps naively he says) state venom should indeed impact conspecs and that if a species needs to avoid venom from conspecs, either they grow a sufficient shell, aim better or code around the impacted location (e.g. if they shoot *.myeye venom, use *.refshoot for conspec recognition instead of *.refeye.
Should bots be able to evolve venom resistance? How should resistance to venom be controlled?
I'd say sure, bots can evolve venom resistance, but not in anyway that the engine is aware of, which is essentially saying no to what I think is the essence of your question. Bots can evolve whatever ways they want to work around the impacted memory location or evolve ways to prevent it from getting overwriten in the first place - thicker shells, etc. but I'm kind of naturally resistant to adding more n^2 feature-specific state for the engine to carry around for each bot. The engine would need to track each bots resistance to each type of venom, we would need to add some sort of *.mkvenres sysvar, etc. or whatever the point being the engine has special case code for this functionality.
Now, this is where a personal philosphy of mine rears it's ugly head. Gack, how do I say this clearly? I think a highlevel design philosophy for DB should be for the DB engine to focus as much as possibile on general physics, on simulating and providing data about artifacts of the bot's world and that it should try to remain out of low level features where possible and be as stateless as possible with respect to how much bot specific, feature specific state it carries around. That is, to a reasonable extent, my preference is for the engine to provide the environment and let specific features such as venom resistance evolve within the DNA. That's not very clear I know, but perhaps using an example....
Say we wanted to provide the ability for bots to dodge shots. On the one hand, we could provide all sorts of special case capabilities for this one feature: *.mkdodge and *.refdodge sysvars, etc. and let the engine do all the work of maintaining state about each bot's shot dodging ability, how that wears off over time, figuring out if and when bots successfully dodge shots, maybe shots with higher .shootvals are harder to dodge, etc. This is what I would term a whole bunch of feature specific code in the engine, a whole bunch of feature-specific state. In this design, the engine would be intemently aware of all the nuances of this specific feature.
But my preference would be to instead enhace the engine to make shots tangable and visable I.e. make them part of the world physics in a general way. Any shot dodging ability would have to evolve or be coded for in a bot's DNA, but so could potentially lots of other features without the engine being explicitly revved e.g. hiding behind veggies, shooting waste as a protective screen, anti-shot shots, child sacrifice, perhaps tieing to a shot? and so on. The engine remains as general as posssible - all it does is calculate who sees what shots and handle the physics of that (yea I know, not trivial) but the point is it remains focused on the physics of the world, providing the environment for specific capabilties/features to evolve or be coded for, but not getting bogged down in feature specifics.
Whew. I needed that.
/Soapbox off
