What issues concerns software when you WRITE a value to EEPROM memory? FLASH memory?

Both are non-volatile but writing them is fundamentally different from writing RAM, and several issues must be handled:

Common to both EEPROM and Flash:

• Limited endurance / wear. Each cell tolerates a finite number of program/erase cycles (EEPROM ~10^4–10^6; Flash often 10^3–10^5 for NAND (SLC highest, MLC/TLC/QLC progressively lower), while NOR is ~10^4–10^5, comparable to SLC NAND and typically higher than multi-level NAND). Frequently-updated data must use wear leveling to spread writes, and you should minimize unnecessary writes (e.g., read-before-write to skip unchanged bytes).
• Writes are far slower than reads. Programming (and especially erasing) takes milliseconds. Software must not busy-block critical paths and must poll a status/ready flag or handle a completion interrupt, and respect the device's program/erase time.
• Verify after write. Read back and compare (or check the device's program-status bits) to confirm the write succeeded; wear and disturb effects can cause failures over time.
• Power-loss during write = corruption. If power drops mid-program or mid-erase, the affected word/page/sector can be left in an indeterminate state. Use brown-out detection/protection, write-completion checks, and a power-safe update scheme — journaling, A/B (ping-pong) copies, checksums/CRC, and a commit/validity marker — so an interrupted write can be detected and rolled back/retried on next boot, leaving the old good copy intact.
• Reads during program/erase may be disallowed on the same bank (read-while-write restrictions), and you must respect the device's program/erase suspend rules.

EEPROM-specific:

• Byte-writable: EEPROM can be erased/written at byte granularity, so updating a single byte is straightforward (no separate erase of a big region). But serial EEPROMs have page-write buffers — you must respect page boundaries (a page write that crosses a page boundary wraps within the page rather than spilling over) and the per-write cycle time (ack-polling).

Flash-specific:

• Erase-before-write and block/sector erase granularity. Flash programming can only change bits in one direction (typically 1→0); to rewrite you must first erase an entire block/sector (setting it back to all 1s). So updating a few bytes may require read-modify-write of a whole sector: copy the sector out, erase it, write it back — which amplifies wear and widens the power-loss vulnerability window. This is why Flash typically sits under a flash translation layer / log-structured filesystem doing wear leveling and bad-block management.
• Program disturb and the need for ECC (especially NAND).