How to epxand macro with optional argument equal to (x,y) so that it becomes part of \path(x,y)--(a,b); inside another macro (expansion problem)?

The idea of pgf keys is precisely to avoid all this optional parameters and getting confused by them. Instead of rewriting all your commands and keeping in mind which parameter means what IMHO it is much simpler to use keys. In the example below, if you want to draw the path with all the default options, just do

\path[L];

If you want to subtract 1, have blue instead of red and south instead of north, do

\path[L={subtract=1,anchor=south,color=blue}];

You can reorder the keys as you want,

\draw[L={color=yellow,subtract=0,anchor=south}];

also works. Another advantage of this method is that it is downwards compatible, i.e. if you decide later that you need to add new keys the old commands will still work without the need of loading a new package.

Full example:

\documentclass[tikz,border=3.14mm]{standalone}
\newcounter{myC}
\tikzset{L/.style={/utils/exec=\tikzset{bp/.cd,#1},insert path={[draw=\pgfkeysvalueof{/tikz/bp/color}] 
(\the\numexpr\number\value{myC}-\pgfkeysvalueof{/tikz/bp/subtract}\relax.\pgfkeysvalueof{/tikz/bp/anchor}\space west)
--(\the\numexpr\number\value{myC}-\pgfkeysvalueof{/tikz/bp/subtract}\relax.\pgfkeysvalueof{/tikz/bp/anchor}\space east)}},
bp/.cd,
subtract/.initial=0,
anchor/.initial=north,
color/.initial=red}

\begin{document}
\begin{tikzpicture}[mystep/.code={\stepcounter{myC}}]
   \path node[draw,mystep](1)at (\number\value{myC},0){one};
   \path[L];
   \path node[draw,mystep](2)at (\number\value{myC},0){two};
   \path[L];
   \path[L={subtract=1,anchor=south,color=blue}];
   \draw[L={color=yellow,subtract=0,anchor=south}];
\end{tikzpicture}
\end{document}

The mystep code is copied from Andrew's answer.

ADDENDUM: Reply to the comment in the question on my answer. It is possible to make something like \path[myLine={north,1}]; work using key filters. However, in your case this would require more thoughts simply because a number is also a valid anchor. So how would TikZ know that 1 is not an anchor but the subtract key? (And personally I find it the suggestion not ver well thought, but of course there are well-thought versions of this, e.g. if you say \node[circle,red,... you do not have to say shape=circle,color=red because TikZ will figure this out for you. But in this case there is no ambiguity.)

It is not clear to me what you are trying to do, but I don't think that you need two macros and that this following code might do want you want:

  \documentclass[tikz, border=5mm]{standalone}
  \usepackage{xparse}

  \newcounter{myC}
  \NewDocumentCommand{\myL}{O{north} O{0}}{%
    \def\myC{\the\numexpr(\themyC-#2)}
    \path[draw=red](\myC.#1 west)--(\myC.#1 east);
  }

  \begin{document}
     \begin{tikzpicture}[mystep/.code={\stepcounter{myC}}]
        \path node[draw,mystep](1)at (\themyC,0){one};
        \myL
        \path node[draw,mystep](2)at (\themyC,0){two};
        \myL
      \end{tikzpicture}
  \end{document}

Here is the output:

Note in particular the use of a .code statement to step the counter. I also added some coordinates for placing the nodes in the path statements since otherwise everything is drawn on top of each other.

The way that pgf does parsing of it's arguments relies on an amount of 'look ahead' code, which takes the input and processes it one step at a time in order to extract possible actions. This is based on the idea that only a restricted range of material can appear in arbitrary positions inside a pgf/TikZ statement.

Here, looking for an optional argument involves an assignment (\let) which is not handled by the internals of pgf. At the TeX level, \let is not expandable so the two possible routes pgf has both fail: it's neither a known case nor something that can be expanded. The result would be an infinite loop, except pgf has a loop counter (set at 100 steps initially), which when exhausted leads to an alternative path giving the error.

As such, this is a fundamental limitation/design decision in how TikZ works. Other answers have tackled the problem in alternative ways, but you cannot use a macro with an optional argument here (at leas without trying to re-write significant parts of the TikZ parser).

Commands with only mandatory arguments do not have to have an assignment 'hidden' inside them, which is why they can work here. (Again, one would need to watch entirely arbitrary content.)