I'll look into autonumbering duplicates. Thanks!

Edit: Fixed. Copypasted metasprite labels will append a unique number ("_1" for example) instead of "_copy" in future versions.

It seems to already be in it. You need to go to Preferences (ctrl+p), pick the Export tab, select "ask metasprite name" checkbox, and click "apply and save".

Thanks for the report! I've been able to replicate it. Seems to be true for the "from cursor" action too.

I'll have it fixed for the next update.

Thanks for the report.

Access violation issue:
-With screen size, do you mean canvas size [ctrl+alt+n], or viewport size (eg alt+w etc)?
-What is/are the actions you performed right before getting the messages? Helper subquestions:
--if using the mouse prior to the errors, where in the interface (and presumably on the canvas) did you click, and with what tool / button combination?
--if using a command/menu action, which one(s)?
--the usual cause for access violations in the past has been trying to place something out of bounds, render something out of bounds, or there's a mismatch of bounds when redoing/undoing (shouldn't happen anymore, but mentioning it anyway just in case), and there hasn't been enough safeguards against it. There can be other causes, but if this rings a bell, let me know. 
-If you can send me the file(s) that have been having trouble so i can try to replicate it, that will problably help too. 

Grids:
Regarding grid sizes, 1 or 2 custom grid size is definitely something i can put on my list of potential todos. It's basically the list i draw from whenever I look for if nice-to-have features have grown more convenient to implement since last I looked (ui changes, code support, etc).

For multi grid clarity, they do a bit of contrast-separation when several are checked, but it's been on my list to make that separation a bit stronger for when lots of options are checked. Double-line is probably not going to happen, but i'll keep the suggestion in mind.  
I would recommend having 2 or less grids checked at a time as a habit; with the exception of screen/32x30 which doesn't get in the way as much. 

Some explanation of the current selection of grid sizes is probably in order.
Their primary incentive to be what they are is connected to nes specific hardware features; which you often find yourself needing to design around:
- 2x is the dimensions of an attribute cell.
- 4x is the dimensions of a byte element on the attribute table describing 2x2 attribute cells. They're specifically meant to help design around these limitations.
- 8x is just a less dense way to orient around such blocks. 
-the screen/32x30 grid has some hardware-fixed relations too. this is the exact size of 1 'nametable', knowing its limits is often useful to calculate stuff, and having it on has implications for optional rules for 4x4 and 8x8 metatile placement that is enough commonplace (like only lay down and count 'half' a 4x4 metatile at the bottom seam - programmers often find this more doable since on the nes you can't just expect it to overflow to the next nametable, since nametables are interleaved with attribute tables). 

Are you sure it isn't in there? It can be hard to distinguish since it uses RLE compression to minimize the text file. 
The reason i ask is that the list items are only a browsing convenience to look at one part of the table at a time.
Everything under one tab is one big table behind the scenes. 

One easier way to verify if it's all there rather than looking at the text output, is to make another session, copy over the chr tiles so things are viewable, then open the produced .mt2 file in that session and see if all the contents are there. 

(As an aside, VarMtClickID=64 can potentially be used as an offset if you want to extract a custom length from the full table. Be sure to click the top left metatile after switching list items but before saving the text file in order to do so reliably)