index.htm is being dropped from URLs upon import

I just don't have a simple answer.
My head has been in a massive project for the last month, and I've only been taking time out to answer ten-minute questions where I can.
This one felt like a 2-hour headscratcher to set up a test version to get it to the point where I could replicate the problem and try to get the idea of what was wanted and why. I know because the internal bit where it collapses the default documents into default folders has a lot of special logic and guesswork around it.

Generally, the idea was to remove redundant .html suffixes by design, and though an option to leave them has been there since the D5 version, it's not the method I'd recommend. On all (static) sites and servers I'd looked at up till now, the path /directory/index.html and /directory/ were equivalent. With the latter being preferred for technical reasons by Apache, webcrawlers, search engines etc.

There may be a short piece of code that could be fixed to make this happen, but there is a chance that doing so would implode all the rest of the logic that calculates child relationships.

/directory/child.html is obviously a child under /directory/
However it's not obviously a child of /directory/index.html, that's just a convention and a special rule.

This is one reason why /directory/index.html gets aliased to /directory very early in the process, so that ALL the other structural stuff can work at all.

What could/should happen is that the full/old alias is kept as a secondary option to prevent link breakage, and that *should* be getting done if the Legacy Aliases option is on.

Optionally, a secondary alias can be made that DOES have the old full suffix. This supports old links and hrefs. You want this unless the source URLS are entirely useless. The new node may end up with two aliases (thats OK) but the tidy one will be used internally by default. Uncheck this if you do NOT want old URL support.

If that's not happening, that's where to look.

Sorry for not letting you know sooner, but my answer is "this could be hard, it may take me half a day and may break any number of other things that will then all need to be retested, and I don't have half a day, and I actually think it's a regressive sort of move to be trying to force file suffixes onto CMS pages - like actually a bad idea, and there's a number of other alternatives like just adding aliases where needed or a simple .htaccess rewrite to convert */index.htm to * (which is what the normal webserver does anyway) but getting into understanding why you'd really be wanting to do this and a discussion about it is headspace I don't have and sorry I didn't reply earlier but I just did not have a good answer and was letting it settle until maybe I had some time to stop what I'm doing all the time now and think of a good answer but I can't dedicate that right now because it needs concentration to think about all the ramifications...

I would not think that that option would help your case at all.
The "resources" mentioned are the images and files that your site may embed or link to. Importing places those files over in sites/xx/files so the HTML needs to be updated to refer to them there.

That option should not be affecting the alias generation of the imported pages.
Your problem sounded more like an issue with the "Legacy Aliases" option

OK, that makes sense then.
Yes, if not moving the files into the Drupal file storage path, then it is safe to not rewrite the resource paths.

By not rewriting, you are leaving yourself open to some issues down the track however if you start to use other Drupal features.
EG a page at /old/path/to/page.htm may comfortably embed an image at /old/path/to/image.jpg simply by going src="image.jpg"

... And this will work. for now.

But if you try to edit that page at node/123/edit, then the image will appear broken.
And if you were to aggregate that page in a view, then the image will appear broken.
The same applies to links to other html pages, and any number of things.

I used to maintain relative links as much as I possibly could, but the fact is, with Drupal (and any CMS it seems) internal relative links really have to be replaced with root-relative ones.

If your links are root-relative (they start with a /) and you've merged your files directly over Drupal core (messy, but possible) then you may be OK.
My warning is about really-relative links - those that go up and across or rely on the source being in a specific folder in relation to the target.

If you have links that use ../../.. to get to the top and down again, those are still just relative and could create problems. It just happens that your webserver/browser is flattening that path sometimes, and it just seems to work.

in import_html, the setting is to shift all files into the files directory and relink to them. As you are not doing that, this is just a potential concern I'm warning about.
If you've rewritten your links to be root-relative (eg wget with the --mirror option does that I think) then you should be OK.

old issue, seems settled