struct constructors are some kind of weird type/path hybrid

[durka]

Is this a known issue?

Consider the following setup:

mod foo {
    pub struct Bar<T>(pub T);
}

You can construct a Bar:

let _ = foo::Bar::<i32>(42);

Now I want to try it with a macro.

macro_rules! construct {
    ($strukt:path, $val:expr) => {
        $strukt($val)
    }
}

The obvious thing doesn't parse at all:

let _ = construct!(foo::Bar::<i32>, 42); // ERROR
//                         ^ unexpected token `::`

We need to remove the second ::, which makes things inconsistent with the macro-less syntax:

let _ = construct!(foo::Bar<i32>, 42); // ok

Why this inconsistency? It seems like a struct constructor isn't really a path. But that's the only macro fragment that can be used in that position (besides ident and tt).

[petrochenkov]

This issue is not related to struct constructors in general, it's related to what path matcher accepts in macros.
Minimal example:

macro_rules! m {
    ($p: path) => {}
}

fn main() {
    m!(a<b>); // OK
    m!(a::<b>); // FAIL
}

There are two flavors of paths (syntactically) - with disambiguating "turbofish" (a::<b>) and without it (a<b>). :: is required in expressions for disambiguation, but in other contexts it's not necessary and should probably just be optional, but is currently prohibited instead (I don't know why, maybe there's a history behind it, maybe not). The issue is that paths passed to macros through path matchers are considered "non-expression" paths.
As I said previously turbofish being rejected in non-expression paths is an artificial restriction and this issue gives a good motivation for removing it.