If you want to call the function like this, you’ll need to manually specify the type of the parameter Q. Either in the function call, i.e. something like parse_flinks::<_, &Path>(&path, None), or for the None, so something like parse_flinks(&path, None::<&Path>). If you want better user experience, you could consider creating two distinct methods, e.g. fn parse_flinks<P: ?Sized + AsRef<Path>>(path_to_flink: &P) as well as fn parse_flinks_with_q<P: ?Sized + AsRef<Path>, Q: ?Sized + AsRef<Path>>(path_to_flink: &P, q: &Q) (where the implementation of the parse_flinks just calls parse_flinks_with_q with the appropriate default value in the second argument).
Could you be more specific about what you didn’t understand? Option<T> does not support unsized arguments for T; but in your original example an argument like &P where P: AsRef<Path>could support unsized types, so I added an ?Sized bound where it’s appropriate in my code examples. This has the effect that you can pass types like &Path or &str directly for the &P argument instead of needing to create double-indirections like &&Path or &&str.
Another alternative is to drop the &s entirely in the argument types and do thing s like fn parse_flinks<P: AsRef<Path>>(path_to_flink: P) instead of fn parse_flinks<P: ?Sized + AsRef<Path>>(path_to_flink: &P). The former is even a bit more general.
By the way, note that my suggestion was to have parse_flinks_with_q not take an Option anymore at all.
If you do still want an option, then parse_flinks_with_q<P: …, Q: AsRef<Path>>(…, q: Option<Q>) would probably be the best option (but something like parse_flinks_with_q<P: …, Q: ?Sized + AsRef<Path>>(…, q: Option<&Q>) would work, too).