Hey Harri,

do not retire an old friend easily.

Re-reading my mail, I may have falsely assumed things as given and been to brief in places.
Rereading yours carefully, I think, I see potential tripping points now.

Why not give it one last fight?

Nevertheless, the following is based on trial 'n error only (quite old trials even, from when I started to experiment with mkgmap), but I manually went through all the motions again right now and the merged maps load well. If things are misinterpreted along the way, please everybody pipe in .

As for the potential tripping points:

Your first mail reads: "I'm generating multiple files [.imgs], all with different family-id, product-id, mapname and map description."
But then your second mail details: "At the moment I have tiles, use mkgmap with some style and then run mkgmap with another style to make overlay like arrows for oneway streets and I need to combine that kind of results."
I'm assuming you start with some Geofabric file, maybe use osmconvert with a bbox or polygone and then splitter, to get the tiles. One argument of splitter should be --mapid. I typically use --mapid=FID0001, e.g. --mapid=64100001 for a map wit FID 6410. These mapids stick with the tiles. If you reuse the tiles for different maps and the try to merge those into one final map, there will be conflicts. Please try, to split separate tiles with separate mapids for each of the maps to be merged.
Also from the first mail: " They all use different typ-files matching the file family/product-id of the compiled map."
- From my understanding, there is no such thing, like a type-file having FID or PID, other than by filename. I know that TYPViewer has FID info in its header section, but afaik that is informal (comment) only. At least, when using UTF8 typefiles (I'm on Linux).
  TYPViewer exports/imports/converts UTF8 <-> .typ. If an UTF8 typefile (having whatever FID in the header) is provided to mkgmap on the commandline, mkgmap too compiles to .typ (on-the-fly, during map generation, saved to the working directory) and uses it for that generated map correctly. Works standalone too, iirc.
- On the other hand, one .img can only use one typefile (although it can contain multiple, see below, 2.nd test). Hence all elements for the final map, must be declared in the typefile used by the map. On merging maps (like we target here), only one of the individual maps typefiles gets used for the result; from the sample below, this could be the alphabetically first typefile (Gerd?). Its selection is not dependant on the order of calling the input files.
  So you can use the same typefile (w/o any modifications/adaptions) for different maps (I do that all the time) but you should take care, that the one used in the merged map has definitions for all elements of all maps merged. Maybe you'd want to use that one for the individual maps then anyway (last sample below).

#1
Lets merge an .img file of Mallorca from 2 separate (simple) .imgs (built using the same, only renamed typefile):

felix@TCHd:~/Downloads/mergetest$ ls -al
insgesamt 92
drwxr-xr-x 2 felix felix 4096 Nov 26 16:41 .
drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 ..
-rw-r--r-- 1 felix felix 61440 Feb 27 2022 Malle-Acuts-6410.img
-rw-r--r-- 1 felix felix 20480 Feb 27 2022 Malle-Bcuts-6420.img
-rw-r--r-- 1 felix felix 710 Feb 24 2020 options.arg

felix@TCHd:~/Downloads/mergetest$ gmt -i Malle-Acuts-6410.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu

File:        Malle-Acuts-6410.img, length 61440
Header:      27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms 0
Mapset:      TKM_Malle-Acuts-6410

Map              length s-f CP    prio PID   FID name
MAKEGMAP MPS        95 1
64106410 MPC     53363 3 1252 60 T    1 6410 TKM_Malle-Acuts-6410
06410FM1 TYP       888 1 1252           1 6410
00006410 SRT       912 1

Data MPS
F: PID 1, FID 6410, TrackMap
V: OSM map set (0)

felix@TCHd:~/Downloads/mergetest$ gmt -i Malle-Bcuts-6420.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu

File:        Malle-Bcuts-6420.img, length 20480
Header:      27.02.2022 19:14:05, DSKIMG, XOR 00, V 18.15, Ms 0
Mapset:      TKM_Malle-Bcuts-6420

Map              length s-f CP    prio PID   FID name
MAKEGMAP MPS        95 1
64206420 MPC     12475 3 1252 60 T    1 6420 TKM_Malle-Bcuts-6420
06420FM1 TYP       888 1 1252           1 6420
00006420 SRT       912 1

Data MPS
F: PID 1, FID 6420, TrackMap
V: OSM map set (0)

felix@TCHd:~/Downloads/mergetest$ cat options.arg
overview-mapname=Malle-6400
overview-mapnumber=64000000
description=TKM-Malle-6400
series-name=TrackMap
family-name=TrackMap
family-id=6400
mapname=64006400
product-id=1
product-version=0815
draw-priority=58
transparent
gmapsupp
input-file=./Malle-Acuts-6410.img
input-file=./Malle-Bcuts-6420.img
output-dir=./
verbose

felix@TCHd:~/Downloads/mergetest$ mkgmap -c options.arg

felix@TCHd:~/Downloads/mergetest$ ls -al
insgesamt 184
drwxr-xr-x 2 felix felix 4096 Nov 26 17:31 .
drwxr-xr-x 13 felix felix 4096 Nov 26 16:41 ..
-rw-r--r-- 1 felix felix 79360 Nov 26 17:31 gmapsupp.img
-rw-r--r-- 1 felix felix 5120 Nov 26 17:31 Malle-6400.img
-rw-r--r-- 1 felix felix   157 Nov 26 17:31 Malle-6400.tdb
-rw-r--r-- 1 felix felix 61440 Feb 27 2022 Malle-Acuts-6410.img
-rw-r--r-- 1 felix felix 20480 Feb 27 2022 Malle-Bcuts-6420.img
-rw-r--r-- 1 felix felix   319 Nov 26 17:30 options.arg

felix@TCHd:~/Downloads/mergetest$ gmt -i gmapsupp.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu

File:        gmapsupp.img, length 79360
Header:      26.11.2022 17:31:21, DSKIMG, XOR 00, V 8.15, Ms 0
Mapset:      TKM-Malle-6400

Map              length s-f CP    prio PID   FID name
MAKEGMAP MPS       174 1
64106410 MPC     53363 3 1252 60 T    1 6410 TKM_Malle-Acuts-6410
06410FM1 TYP       888 1 1252           1 6410
00006410 SRT       912 1
64206420 MPC     12475 3 1252 60 T    1 6420 TKM_Malle-Bcuts-6420
06420FM1 TYP       888 1 1252           1 6420
00006420 SRT       912 1

Data MPS
F: PID 1, FID 6410, TrackMap
F: PID 1, FID 6420, TrackMap
V: OSM map set (0)

Discard ...6400.tdb and ...6400.img and rename gmapsupp.img, if you so like. Loads fine, identical to stacking the individual maps.
These are very simple map overlays I built from scratch from .gpx tracks only; very few ways and 1 tile per map only.

#2
But the process functions as well, if I use a small bbox full "basemap" (FID 5403) and my much wider bbox transparent cyclenetwork overlay (FID 7121), both built from OSM data as outlined above. Here the merged map has way more tiles, shows many elements only for the small bbox and only the CN ways outside, but it is only based on my "BICYCLIN TYP" (used for 7121) and the (mkgmap?) inbuild standard typ for the rest, but not the "EDGE_NL- TYP" (used for 5403). See my initial remarks regarding typefiles.
It's not that easy to fix that sample on the fly (since both typefiles declare identical element types differently), but I think, separating that and using one typefile for both maps declaring all elements unique would do the trick.

felix@TCHd:~/Downloads/mergetest2$ gmt -i gmapsupp.img
gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu

    File:        gmapsupp.img, length 68075520
    Header:      26.11.2022 17:57:05, DSKIMG, XOR 00, V 8.15, Ms 0
    Mapset:      Harri-4567

    Map              length s-f CP    prio PID   FID name
   MAKEGMAP MPS     19366 1
   54030001 MPC   2754928 3 1252 31       1 5403 DE-Coesfeld
   54030002 MPC   3449556 3 1252 31       1 5403 DE-Duelmen
     54030003 MPC   2673582 3 1252 31       1 5403 DE-Bocholt
   ...
   EDGE_NL- TYP     28399 1 1252           1 5403
   00005403 SRT       912 1
   71210001 MPC    128048 3 1252 40 T    1 7121 DE-Cuxhaven
   71210002 MPC    107451 3 1252 40 T    1 7121 DE-Husum
   71210003 MPC    109457 3 1252 40 T    1 7121 DE-Husum
   71210004 MPC    146058 3 1252 40 T    1 7121 DE-Elmshorn
   ...
   71210040 MPC     76301 3 1252 40 T    1 7121 NL-Den Helder
   71210041 MPC     77985 3 1252 40 T    1 7121 NL-Harlingen
   ...
   71210161 MPC    133738 3 1252 40 T    1 7121 BE-Verviers
   ...
   BICYCLIN TYP       842 1 1252           1 7121
   00007121 SRT       912 1

   Data MPS
   F: PID 1, FID 7121, osm_dep-nwh-bcsurf-wide_7121
   F: PID 1, FID 5403, osm_deh-tc_5403
   V: OSM map set (0)

I'm somewhat pressed on time atm to fully check that last assumption, but I will put that on my bucket-list too, at least to evaluate, if this tecnique (merging layers of different draw priority into one final map) finally allows, to control the draw-priority of elements (e.g. ways), at least to some degree. That is, to make sure your oneway arrows get plottet on top of the relevant roads...

#3
I did one final test though; merging 2 maps created using the same typefile, but with different, non-overlapping bboxes. No problem!
Please note, the FID 5406 maps typefile (EDGE_NL- TYP) is not even listed by gmt, hence not even included by mkgmap. That would (will?) be my way to tackle this task.

felix@TCHd:~/Downloads/mergetest3$ gmt -i gmapsupp.img
    gmt v0.8.220.853b CC BY-SA (C) 2011-2015 AP www.gmaptool.eu

    File:        gmapsupp.img, length 147324928
    Header:      26.11.2022 18:45:09, DSKIMG, XOR 00, V 8.15, Ms 0
    Mapset:      Harri-4567

    Map              length s-f CP    prio PID   FID name
   MAKEGMAP MPS      2868 1
   54030001 MPC   2754928 3 1252 31       1 5403 DE-Coesfeld
   ...
   EDGE_NL- TYP     28399 1 1252           1 5403
   00005403 SRT       912 1
   54060001 MPC   4410896 3 1252 31       1 5406 DE-Bremervoerde
   ...
   54060030 MPC   2392746 3 1252 31       1 5406 PL-Szczecin
   00005406 SRT       912 1

    Data MPS
   F: PID 1, FID 5406, osm_deo_5406
   F: PID 1, FID 5403, osm_deh-tc_5403
   V: OSM map set (0)

Please keep me posted, if you give it another try.

Cheers Felix