Would be great if robots could place them from blueprints

They can, you need to configure mod. In config.lua you need to specify which lengths will are craftable by player and then bots can place them. (At least i think so, didn't try in 0.15)

I didn't test in 0.14 but it doesn't seem to work in 0.15
I did "enable" it in the config

I just tried it with 0.15 and it works. I had this in config:

MergingChests.ChestRecipes = { 6, 7, 8, 9, 10 }

And those chests were available to hand craft. Are you sure you don't have:

MergingChests.ChestRecipes = { }

in some next line? That would reset it back to no recipes.

Oh I'm dumb. I didn't realize that you had to craft them. I figured that the bots would lay them from regular steel chests.

It works fine now. Thanks.

Hummm... It looks like we don't have to make some types of long chests craftable to blueprint 'em. I haven't checked yet, but IMO you can handle the "on pre built" event removing long-chest-ghosts and replacing it with number of steel-chest-ghosts. You can even "remember" the removed long-chest-ghost to "merge" these steel-chests like as if you selected them using the tool. Or you can replace the number of steel-chest-items in the inventory and add a long chest to be placed by bots.

I looked and i didn't see any event that would be called when blueprint is placed. Is it standard on_built_entity with entity having some flag set that means it is a ghost?

Replacing wide chest ghosts with their steel chest equivalents seems like a good idea, but i don't know about mergin them when all chests are placed. Sure, i can store very wide chests that is planned to be built somewhere and check on_built_entity to merge them. But how do I handle canceling blueprints?

And replacing steel chests in your inventory with needed wide chests. Also i dont know about that, what if you dont have enough at the time of blueprint placement?

I'll try to find answers. I've already got some thoughts on it, but need to RTFM a little bit.
As I know, ghost entity has got "entity-ghost" entity.name.

Can I already use the 1.7.0 code?

Sure and good luck.

Try this out: https://pastebin.com/9D7hvdWX
Looks like works fine. If it fits, my snippets are WTFPL and I don't require any mentioning in credits.

Now there's no need in crafting recipes for the long chests to let them be buildable using blueprints. When you place a blueprint, the mod splits the long chests ghosts into groups of steel chests ghosts and starts waiting 5 minutes for each group. If during this period the mod sees that entire group of steel chests has been placed, it merges them into a long chest. If the waiting period has expired - you should merge them using the tool. So you can either have enough steel chests in your inventory or in a logistics network or in both summed. And if some chests have been filled until all chests in the group were built, their contents just goes to the long chest like before (it means, that if inv size is limited you still can lose your stuff).
EDIT: I'm sure it's possible to move the "waiting process" to the on_built handler - so you won't need the ticker. But it works just fine so there's no real need, IMHO. The present algorithm (with ticker) is also compatible with Bluebuild mod - for those who uses it.

Uhh, I will look into it after work. Nice workaround of canceling blueprint placements. This will also mean that mod can be configurable using ingame settings, which will be nice.

But there's an issue with wires... I ignored them, but could remember to restore then. So now they're not blueprint-buildable.

Ok i got little time to go through the code. I will leave merging in on_tick since it shouldn't require too much work but if it's performance drag I think on_built should work even with Blueprint mod (something still has to place those entities).

I'm still at work but i was thinking and I will test is when i get home. This method has fast_replace field that may connect merged chest to it's ghost circuit connections. I will just set same time_to_live to wide chests ghost so it disapears when it's data are removed from global table (also it will be nice to see how much time i have to finish constructing them).

Also I may have figured out how to remerge merged chests, soon in 1.8.

And do you know if selection tool can be hardwired to filter only specific items like deconstruction planner can be configured in game?

Nope, fast_replace doesn't work. It just deletes all entities under new created entity. Also ghost blueprints disapear if something is placed on them. I will still release new version with this functionality and look around factorio API for another answer.

hardwired to filter only specific items

You can setup some selection flags, but that's all... I don't think it's just what you wanted. Tried to add:

entity_filter_count = 1,
item_filters = {"steel-chest"},

to the merge-chest-selector item proto, but it didn't work as expected, because it's not deconstruction planner.

Also my algorithm doesn't restore long chest's inventory restriction (those red slots) when blueprint-built... Forgot it))) I can fix, if you want.

I wanted to filter what can be merged before area is selected. Like: "Only steel chests, wide chests and high chests can be selected with this selection tool", but that doesn't seems to be possible.

Yeah, also forgot about red slots, I will add it.

Ok, i don't know how to extract red slots count from ghost entity because it doesn't have inventory.

How do you usually do it (for non-ghosts)? If you'll answer - maybe I'll understand.

EDIT: LuaInventory.get_bar(). Ok, trying to extract red slots...

No way))) I mean no simple way. We can place a ghost with bar (that red limiter) by specifying "create_entity{... bar = start_after ...}" for a container ghost/container. But We can't get this value from the ghost. We can only read a blueprint in cursor_stack, find the blueprint part of this entity-ghost calculating aligns and then get the needed value there. No other way exists today. I'm going to post in modding interface requests.

EDIT: OR!.. We can revive this ghost, get its inventory, remember the bar value, then split it into steel chests ghosts! Several steps on the same tick won't cause any losses I suppose...

EDIT 2: The bar is integer value, it says after which slot the inventory should be unoperable. By default it's "bar = #inventory" So, when we split a long chest we should give each resulting steel chest "bar = long_chest_bar/long_chest_size", approximately. Then, after merging, just summarize bars of steel chests. Or just give it initial bar.

Reviving seems like not entirely bad idea. It's not perfect but until game API doesn't support this, there is little choice.

Splitting bar value to created ghost steel chests should work also, and while i'm at it I should probably use same code for merging using area selection.

One guy advised to .revive() -> get bar -> .die(), so we'll get a ghost entity with the same properties. But I think it'll spoil the game statistics ("Buildings destroyed" point).

Reviving of ghost is also not possible. What something needs to be removed before entity can be placed (like tree or entity planned for deconstruction). Revive wont work then.

AAAaaah! This is really hard :D I would really like to avoid browsing blueprint for correct entity (and maybe even then it wont be possible to read bar count).

Simple small handy mod becomes monstrous, the code creeps out of the screen, horizon of new features comes closer )))))

Maybe I'll just skip bar count for now and do it next release. Even wires aren'T resolved in this. :(

And yeah... 13kB for control.lua now. Kind of ridicilous.

yep, bar is not so necessary as wires. agreed.

I need a vacation...I'm almost sure some bugs got through because of all modifications. There probably are some special edge cases where merging of merged chests with other merged chests will result in a incorect merging.

Oh my goodness, we need some sanity check when it comes to chest sizes. I blew mine up to max h/w = 512/512 and max area 7200 and now Factorio won't finish to load anymore and eat up >20GB of rams in the process... holy shit! (sorry)

Limit max chest area first, that will help the most.