Memoir and tcolorbox A was supposed to be here

The problem seems to be an incompability between mparhack and the shipout/background hook.

You can as workaround until this is fixed suppress the loading of the package:

makeatletter
disable@package@load{mparhack}{}
makeatother
documentclass[twocolumn]{memoir}
usepackage{tcolorbox}
begin{document}

blub

end{document}

The problem is that mparhack redefines hb@xt@ in the output, and this command is used in various places, beside others in put, and this means that the code in the shipout/background hooks fails. So another work around is this:

documentclass[twocolumn]{article}
usepackage{mparhack}
AddToHook{shipout/background}{put (0,0){}}
makeatletter
longdefput(#1,#2)#3{%
  @killglue
  @defaultunitsset@tempdimc{#2}unitlength
  raise@tempdimc
  hbox toz@{% <--- instead of hb@xt@
    @defaultunitsset@tempdimc{#1}unitlength
    kern@tempdimc
    #3hss}%
  ignorespaces}
makeatletter  
begin{document}

blub

end{document}

As Ulrike said, the problem here is that the package mparhack attempts to patch the kernel command @dbloutputcol and inject some code into it. To make its life easier it simply redefined hb@xt@ which is used there and replaces that under certain conditions (when the first argument is columnwidth) with its own code --- if not it tries to execute the original code (which is basically hbox to). Unfortunately that breaks very badly in other places where the kernel and package use hb@t@, i.e., whenever it is used and has to be expandable, for example inside put where the code looks like this

   raise hb@xt@ ...  % means raisehbox to ...

After mparhack has acted this now looks like

   raise defmph@tempa{}hbox to

an def is not a box hence the error.

Midterm mparhack.sty needs a correct patch (or should vanish eventually), short term, here is a firstaid that we should apply from the kernel side until the package gets fixed. I didn't do much just made sure that hb@xt@ remains expandable and expands to hbox to normally (there are better ways to address this):

makeatletter
defmph@outputdblcol{%
    defmph@chk@dcl{0}%
    defhb@xt@##1##2{%
        ifx##1columnwidth
            mph@step@cntmph@chk@dcl
            protected@edefmph@tempa{%
                noexpandwritenoexpand@auxout{%
                    noexpandstringnoexpandmph@setcol{%
                        romannumeralmph@chk@dcl:noexpandthepage%
                    }{%
                        noexpandstringnoexpandmph@nr%
                    }%
                }%
            }%
            mph@orig@hb@xt@##1{##2mph@tempa}%
        else
            mph@orig@hb@xt@##1{##2}%
        fi
    }%
    mph@orig@outputdblcol
    defhb@xt@{mph@orig@hb@xt@}%
    ifnummph@chk@dcl=0relax
    else
        ifnummph@chk@dcl=2relax
        else
            mph@error{string@outputdblcol}%
        fi
    fi
}

AddToHook{package/after/mparhack}{let@outputdblcolmph@outputdblcol}
makeatother

%----- above needs to happen before mparhack is loaded or rather fixed there


documentclass[twocolumn]{memoir}



usepackage{tcolorbox}

begin{document}

tekst

end{document}

As a final remark, especially also in the light of the claims made in Are the latest TeXLive updates failing to provide backwards capability? in the comments:

• yes with more activity, bug fixes and extended functionality, new releases of LaTex may break things (any change has that ability)
• but it very often simply shows hidden bugs or misuses that are lurking in many of the aged packages ... seriously you can't alter something as low-level as hb@xt@and change its semantics and then say it is LaTeX's fault if this breaks when all we do is using it as defined by the kernel. And in that particular case the authors must have seen the problem in the past as they tried to fix it for eso-pic which does (more or less) what is now offered as a standard functionality in the kernel.
• so yes things can break, but seldom silently, but so far such breakages have been mended by the package authors or by us (and usually for the better) because typically the true cause was a lurking issue that just showed its face

Update 2021-05-04

mparhackgot the necessary patch and it showed up on TL by now. This means that the problem should be gone. As a side-effect mparhack should now also work correctly in older LaTeX releases, for example, in TL18 where it broke the document

documentclass{article}
usepackage{draftwatermark,mparhack} 
begin{document} X end{document}