Not sure I fully understand the bug, the image you want to upload that is merged, is that one contagious area with just one MCUboot header/trailer/signature for the whole area, or 2? If it is 2, you cannot upload it as a single file. Or do you mean that the _ns partitions are not used by MCUmgr?

The image is one contiguous area, with a single header and trailer. In essence, slot0_partition + slot0_ns_partition (as required by TFM_MCUBOOT_IMAGE_NUMBER == 1).
But, based on the devicetree partitioning, all the flash area operations are on the flash area corresponding with slot0_partition.
Hopefully it is obvious why any image operations would fail given that.

In fact I suspect (but have not tested) that this is broken for TFM_MCUBOOT_IMAGE_NUMBER == 2 as well, given that it is looking at the secure partition, not the non-secure partition.

My plan on resolving this downstream is to tweak how the partitions are defined so that mcumgr gets a handle to the complete flash area, while still preserving the secure/nonsecure partitioning for other tooling:

		slot0_partition: partition@10000 {
			label = "image-0";
			reg = <0x00010000 0x000F0000>;
		};
		slot0_s_partition: subpartition@10000 {
			label = "image-0-secure";
			reg = <0x00010000 0x00030000>;
		};
		slot0_ns_partition: subpartition@40000 {
			label = "image-0-nonsecure";
			reg = <0x00040000 0xC0000>;
		};

The subpartition node name is required to avoid defining two nodes with the same name (partition@10000).
Note this sort of change would be made much easier upstream with #74707 (Which I note you have approved 👍).

I think we should separate partitioning from board definitions and provide something like partitioning profiles, for example: default, mcuboot and tfm, that would be given to a build as an option.

I think we should separate partitioning from board definitions and provide something like partitioning profiles, for example: default, mcuboot and tfm, that would be given to a build as an option.

Where would these profiles live, and how would they handle a secondary image that lives on external flash?

Where would these profiles live, and how would they handle a secondary image that lives on external flash?

I had two ideas for that, one was that every board defines these profiles that it is supposed to work with, as overlays - probably a lot of work.
Second was to define a templates for them and boards would have configurations for templates.

I have already off-line talk with @nordicjm regarding above and see how hard that would be to implement.

One of the reasons I wanted to have at least the mcuboot and default profile was so that both mcuboot and non-mcuboot builds would use zephyr,code-partition selected partition, but it's definition would just change; this would solve the problem where mcuboot build of an app is aware of how it is limited to a certain partition, while non-mcuboot builds ignore partitioning and can span into other partitions, like storage.