"Allow overlapped sections" tells the linker it is free to place two or more variables or code at the exact same address in RAM/flash. This option should never be enabled, except for the purpose of debugging an immediately preceding "Section '...' overlaps ..." linker abort message. Enabling this option suppresses this type of linker abort, allowing full .map and .elf files to be generated for analysis. However, immediately afterwards, it should be returned to its default unchecked state because your .hex output artifact will either fail spectacularly at run-time, or be subject to failing spectacularly at any future point in time when you rebuild the project.
Removing this option definitely is a correct thing to do. Any error is possible if RAM variables are being overwritten by other RAM variables. Catastrophic run-time outcomes can happen with any project when overlapped sections are allowed, with or without dependency on EZBL components.
I have read the thread regarding the multiple __reset definitions linker abort. However, I am no better able to understand what is happening because of it. As far as I can tell, such an error shouldn't happen. I cannot reproduce the problem at all. Also, because XC16 defines both of the __reset definitions that are in conflict, I can't discern if the underlying problem exists in EZBL, in XC16, in the way MPLAB X IDE is calling XC16, in your particular project settings, or on your particular PC due to conflicting GCC/GCC-derived/Cygwin tools in the system path or environment variables.
The output window data you provided unfortunately does not help. I need to see the linking command line itself, not the output from the linker. For example, please share the immediately preceding line that looks like this:
"C:\Program Files (x86)\Microchip\xc16\v1.35\bin\xc16-gcc.exe" -o "C:\ezbl-v2.11\ex_boot_uart\ezbl_integration\ezbl_partial_link.elf" build/uart/production/hardware_initializers/dspic33ep512gm710_explorer_16.o build/uart/production/hardware_initializers/pic24fj128ga010_explorer_16.o build/uart/production/hardware_initializers/dspic33ep512mu810_explorer_16.o build/uart/production/hardware_initializers/pic24fj256gb110_explorer_16.o build/uart/production/hardware_initializers/pic24fj256ga110_explorer_16.o build/uart/production/hardware_initializers/pic24fj64ga004_explorer_16.o build/uart/production/hardware_initializers/dspic33ep256gp506_explorer_16.o build/uart/production/hardware_initializers/dspic33fj256gp710a_explorer_16.o build/uart/production/hardware_initializers/pic24fj1024gb610_explorer_16.o build/uart/production/hardware_initializers/pic24fj256gb410_explorer_16.o build/uart/production/hardware_initializers/dspic33ep64gs502_digital_power_starter_kit.o build/uart/production/hardware_initializers/dspic33ev256gm106_can_lin_starter_kit.o build/uart/production/hardware_initializers/pic24fj64ga104_explorer_16.o build/uart/production/hardware_initializers/pic24fj128ga310_explorer_16.o build/uart/production/hardware_initializers/dspic33ch128mp508_explorer_16.o build/uart/production/hardware_initializers/pic24fj128gc010_analog_starter_kit.o build/uart/production/main.o build/uart/production/emulated_eeprom.o ezbl_integration\ezbl_lib.a -mcpu=24FJ1024GB610 -omf=elf -DEZBL_BOOT_PROJECT=uart -DXPRJ_uart=uart -legacy-libc -Wl,-DEZBL_PASS_1_LINK,--defsym=EZBL_BOOT_PROJECT=1,-DEZBL_BOOT_PROJECT=EZBL_BOOT_PROJECT,-D__24FJ1024GB610__=1,--local-stack,,--defsym=__MPLAB_BUILD=1,,--script="ezbl_integration\ezbl_build_standalone.gld",--stack=16,--no-check-sections,--data-init,--pack-data,--handles,--no-isr,--gc-sections,--fill-upper=0,--stackguard=16,--no-force-link,--smart-io,-Map="dist/uart/production/ex_boot_uart.production.map",--report-mem,--memorysummary,dist/uart/production/memoryfile.xml,--defsym=_BOOTID_HASH0=0xFE07C793,--defsym=_BOOTID_HASH1=0x57F877D8,--defsym=_BOOTID_HASH2=0xCD24AEBD,--defsym=_BOOTID_HASH3=0x4854ADED 1>NUL
Back on the topic of UART2, the three lines you uncommented in the bootloader definitely will cease all background EZBL behaviors. However, the UART peripheral itself will still remain in the same state it was while the Bootloader was using it. This may or may not be compatible with the way your Application tries to reinitialize and use the UART.
Notably, U2MODEbits.UARTEN will stay == '1' when the Application starts, which means hardware will block certain configuration changes from taking effect. For example, U2MODE<ABAUD> cannot be cleared by software whenever the UARTEN bit is set. I believe U2STAbits.UTXEN also becomes read-only.
To put all UART2 SFRs and internal state (like the hardware TX and RX FIFO contents) in a freshly reset state, regardless of their prior state, you should execute:
_U2MD = 1;
_U2RXIP = 4;
_U2TXIP = 4;
_U2RXIF = 0;
_U2TXIF = 0;
_U2MD = 0;
Execute this either in the Application before you try to initialize UART2 for your Application's use or in the Bootloader before launching the Application. The act of setting then clearing the PMDx<U2MD> bit will auto-reset all peripheral level SFRs and internal state, so you don't have to worry about existing U2MODE/U2STA/U2BRG values.