I must report that when you change the Canavas resolution, the selection starts to crash and the application becomes uncontrollable at times (I changed the resolution to 256x256).
Yeah unfortunately Somewhere around 8 by 8 or more screens performance starts to scale poorly. Especially the Navigator is problematic so i recommend using it sparingly on such large canvases, until i've found good ways to avoid redundant calculations.
That the tileset selection should be affected by this is more than just a performance issue, though. I'll make a note to look into that specifically. Thanks for the report!
I don't think this information will be useful to you, but if in doubt, the last time I did a similar job with NEXXT was in v0.10.1b, and I didn't have any problems on that occasion.
Also, just in case, I tried to export the attributes and the following happens (It wrote 256 lines not counting the header [It is configured to store only attributes]):
Perhaps what makes the application slow is related to the problem I had previously reported.
I'm still not sure what's going on there. When i try to replicate the problem, i get consistent results: 64 bytes of attribute table if exporting for a single screen, 128 bytes for 2 screens, and so on.
First step, make sure you're using "save screen as asm". The "+ include names" and "+ include attributes" in the options submenu only govern the two actions belonging to the same subsection below the menu divider.
If that still fails, i recommend you send me the session file so i can have a look at what's going on. If there's a bug, the file will help me point me to it. 
I'm not saying i'm putting your judgment into question. Apologies if it came across as that. It's just that i need to narrow it down and double check to make sure what the problem is behind the phenomenon of it, so to speak, and where it may be located.
Hm. The file link says "special stage", but the file i'm getting clicking on it is the one containing your custom icons. Strange.
In any case. This is another possibility: A canvas size of 256*256 means attribute data equivalent to 8 by 8 screens, that is 64 bytes * 64 screens. Or 4096 bytes in total.
The .byte emissions in your screenshot seems to be 16 byte statements (correct) * 256 lines. In other words, 4096 bytes.
It would seem to me the attribute data is correctly sized.
That is, Unless you want the attribute data for a single screen, rather than for the total of your session.
In that case, you (currently) need to copypaste a screen-sized selection over to a secondary instance of NEXXT, whose canvas size is 32x30 or 32x32, and then export that to .asm
Let me know if that's helpful. Meanwhile, I'll put it in my todo list to look over more options that could make this process faster and more intuitive.
As of v.0.22 (now uploaded), the menu action is more appropriately named "save canvas as ASM" instead of "save screen as ASM".
Sorry, I didn't remember I had another file with the same name uploaded, I copied the wrong link: Special Stage NSS (7z)
Thanks! That clears it up.
The output *is* the intended behaviour. It takes the attribute byte of each 4x4 tile region on the map and outputs it, going left to right, iterated top to bottom. This results in 4096 bytes representing the entirety of the map.
I'll look into an action for just saving current selection. Pressing ctrl+a once, that means the currently viewed portion of the screen.
Additionally, the file helped me find another bug: It seems the status readout bar provides wrong data element on maps that aren't exactly 1 screen wide. Thanks for providing the opportunity!
Many thanks to you, the retro community owes you too much! I would like to take this opportunity to recommend this web application, perhaps this tool will be useful for your projects: https://rilden.github.io/tiledpalettequant/