When using --mount-proc=/some/path then unshare fails if the path provided is not already mounted due to the mount(2) call to change the propagation of the mount.
In such a case mount(2) returns EINVAL, which however is used for a variety of other errors.
If this error is ignored mistakenly the effects however should be negligible since:
1. the mount of proc afterwards happens regardless, errors of which are not ignored
2. the propagation change of root uses MS_REC, which should already change the propagation of all mounts recursively
Furthermore /proc is not touched if --mount-proc specifies a different mount point.
This should not cause too much unexpected behaviour due to point 2 from above in any case.
Specifying --mount-proc with a different path also means that unshare(3) is not instructed to touch /proc, thus /proc not being touched should not be unexpected.
As a side note, if unshare is called with /proc as an (implicit) parameter to --mount-proc then /proc is a stacked mount, meaning if /proc is unmounted within the namespace the host /proc will be visible again, thus not touching /proc with a different parameter does not constitute more information leakage than the alternative, quite contrary it may even be the desired behaviour.