Firstly, I was wondering whether it is worth checking no-en-passant and poorer-castling-rights in the transposition table look up. The reason I ask is that I reckon that an en-passant target rarely contributes to the value of a position for the side to move -- so all you're doing by including en-passant is cutting off access to entries in the table that could provide valuable information. As for castling rights, these probably add more value -- but it might still be useful to see the best move/score without castling rights.
Do you think it would be worth the cost to check no-en-passant-target and similarly, poorer-castling-rights positions in the transposition table to see if they produce cut-offs? -- it would cost up to three extra look-ups -- since you'd want to check the position without en-passant, the position without QS-castle and without KS-castle (provided the position had these features) -- which you could do just by xor-ing them out of the Zobrist key. Has anyone experimented with this kind of thing?
My second question is about move evaluation. At the moment I'm just using an extremely simple evaluation that only includes material and piece-square values (which I found here) which I have incorporated into a single array so I can evaluate moves without making them. I would like to know if anyone has experimented with dynamically modifying piece-square tables during the search in order to coax the emergence of more nuanced positional evaluation that is static piece-square tables can't do. The kind of system I have in mind is that each time the search function hits a new node, it increments the scores in the piece-square table of the last few moves that led to the currently search position. This would put a higher value on 'hot' squares, that are continually being attacked and defended -- over 'cold' squares, that may otherwise have been overvalued by static piece-square tables.
The main problem with this I think will be choosing the increment value -- too little and it would have no effect; too much and the positive feedback will send the search function on a wild goose chase. Other problems are of when to decrement piece-square scores, so that the table remains fairly normalized; and the fact that a given move will no longer have a 'unique' score, as it will change over time -- which could cause some tricky integration with transposition tables.
Anyway thanks for listening. If you have tried anything similar to what I've talked about (or if you think it has no chance of working

ps. quick technical question -- in piece_array[64], should I be using chars to save memory, or ints for speed?