This is not a notice of intended change, but rather a solicitation for comment.
We currently default the number of slots on a host provided via hostfile or -host to 1. This is a historical "feature" driven by the fact that our initial launch system spawned daemons on the remote nodes after we had already mapped the processes to them - so we had no way of guessing a reasonable value for the number of slots on any node.
However, the "vm" launch method starts daemons on every node prior to doing the mapping, precisely so we can use the topology in the mapping algorithm. This creates the possibility of setting the number of slots on a node to the number of cpus (either cores or hardware threads, depending on how that flag is set) IF it wasn't provided in the hostfile.
This would have an impact on the default "byslot" mapping algorithm. With only one slot/node, byslot essentially equates to bynode mapping. So a user-provided hostfile that doesn't give any info on the number of slots on a node effectively changes the default mapping algorithm to "bynode". This change would alter that behavior and retain a "byslot" algorithm, with the number of slots being the number of cpus.
I have a use-case that would benefit from making the change, but can handle it outside of the main code path. However, if others would also find it of use, I can add it to the main code path, either as the default or via MCA param.