The idea was to use the map sprite as a special icon when looking at the status screen (e.g. on the map) but I ended up never using it (I did a code search and there's no hits for it) so you can go ahead and use it for whatever you want! :)
Internally it's global.monster_data[monsterID,mond_SPRITE_SMALL] ("SPRITE_SMALL" rather than "SPRITE_MAP")
The game already keeps track of which monsters you've owned, the global.monsters_caught array (indexed by monster species ID). So for instance you could have enemy side's obj_battlemonsterhud check if global.monsters_caught[global.active_monster_party[monster.amp_id,amp_MONID]] is true (and if so, draw the "owned" icon)
You can check how many enemies are alive by running
var num_alive = 0;
for(var mon = AMP_FIRST_ENEMY; mon < AMP_FIRST_ENEMY + PARTYSIZE_MAX_ENEMY; mon++){
if(global.active_monster_party[mon,amp_HP] > 0){
num_alive++;
}
}You'd probably want to count once at the start of the battle (within bcontrolstate_ANNOUNCE_TRAINER) to get the TOTAL amount of monsters, and then count the number of currently available ones in the Draw event (so you can cross out KO'd monsters when drawing)
Currently evolutions already are an array, with zero or more tuples [type, parameter, evoSpecies]. For item split evolutions you could just add them there, but be triggered by different items.
For levels I'm thinking the easiest would be adding new evolution types, e.g. evotype_LEVEL_SPLIT_PHYS_ATK and evotype_LEVEL_SPLIT_DAYNIGHT_PHYS_DEF for a monster that becomes one species when its ATK is higher and another if its DEF is higher. These come in pairs (or triplets, etc), one type for each "branch" of evolution and then you'd give the monster one evolution tuple for each branch. (So e.g. [[evotype_LEVEL_SPLIT_PHYS_ATK, 10, mon_SWORDY], [evotype_LEVEL_SPLIT_DAYNIGHT_PHYS_DEF, 10, mon_SHIELDY]] as the evolutionlist)
The script amp_earn_exp is also responsible for keeping track of pending evolutions, and currently it only checks for evotype_LEVEL here. You would add the new types here as well, but have them only enqueue the new evolution if the condition for that "branch" is met (and then make sure to write conditions so that only one can be met at a time)