I don't know why i had to do snap forks, I guess just to try it out..
I couldn't come up with a hyperblocks method but modified a project from the recent Snap! course to give a low code similar effect
Brilliant idea of using background image clipped by sprite used as mask 
It can be further simplified to stamping without clones.
BTW: there is no need to show sprite before stamping/pasting.
The paste on block doesn't seem to be affected by the color graphic effect.
Yes, that's right. paste disregards graphic effects both on the pasted and the pasted-on sprite. it does take into consideration (relative) size, position and rotation, which lets you do all kinds of interesting effects yourself. And you can also paste a sprite onto all clones of another sprite simply by choosing the original's name. That way you can create a multi-part jigsaw-puzzle or a swarm-picture in a single pass. Example:
Oh, embedding projects is disabled right now, here's the link: https://snap.berkeley.edu/snap/snap.html#present:Username=jens&ProjectName=SAP%20Flag&editMode
Oh yes, that's a good idea for making visual "holes", thank you! But it wasn't my real goal 
It was just a part of a more complex task. Here is another example:
Move mouse to aim, press SPACE to fire. You see here: cannonballs damage the terrain. I have a terrain sprite and a "sky" sprite to paste on the terrain to emulate shell craters, similarily to what you do. Now I use "touching color" sensor to detect when and where a cannonball hits the terrain. This approach has two problems:
- I want the terrain to have a texture. But now it must be of one solid color to use "touching color" sensor correctly. It also implies that the background picture should not have this color on it.
- "touching color" sensor is quite slow.
That's why I'm looking forward to use "touching sprite" instead, because it solves both issues. And that's why I try to make some parts of the terrain sprite really transparent - so that "touching sprite (= terrain)" sensor can return "false" when a cannonball is over these transparent parts.
So I end up manually altering (i.e. setting the alpha value to zero of) terrain's pixels near the impact point, and it's quite slow. It would be great to do this with some kind of "paste on" blocks. Is it possible, @jens?
OMG, this project is awesome! Would you mind publishing it so I can feature it?
maybe you could try pasting another sprite whose costume is almost-fully-transparent on it, with a very low alpha value? Oh, wait, no. Pasting only adds, never subtracts.
Let me think about this...
Oh... For me it's just a draft to put the basic mechanics right... But if you think it's worth featuring, I won't mind.
What about?...
or even
see, that's the problem with every feature that I put in. I'm putting a ton of effort into selecting the one setting that will open up the most broad range or activities. And then people want drop-down menus, buttons and settings. And THEN everything turns into Microsoft Office and becomes unusable.
Now, let's find a smart way, or not do it altogether.
Yeah, you've opened the Pandora's box when introduced pasting of one sprite onto another It opened a totally new approach to sprites handling and graphic effects, a new degree of freedom, that's why we need more
You can check to see if touching one of the the looking glass clones - reload my project and use extra sprite to test this with
Yes, I've thought about that too. But there will be a problem if the terrain sprite is not simply a rectangle but initially has transparent parts (like in my "cannons" project). So we'll need a "background" sprite too that wil be partly visible from the beginning. Thus we'll have to use complex condition to detect terrain impacts: cannonball NOT ("touching lookinglass" OR "touching background"), but this will cause errors in areas initially occupied by terrain sprite and background sprites: impacts in these areas won't be detected because "touching background" will be true there. Hope my explanation is clear.
Yes 
Unfortunately, its my lack of understanding of your native language makes its very tricky for me to play with your projects and modify them as I don't understand the variable and sprite names
Ok, I should have thought about that
Translated both projects to english.
Thank you for your efforts!
What about this?
Click anywhere on the ground to punch a hole.
It's not instant, but maybe it's fast enough for your project...
that's pretty fast and beautiful, Bernat!
Thank you Bernat. That's an interesting idea to use "paste on" as an intermediate step!
But it's still very slow... Look, I've remixed your project a bit to match mine: https://snap.berkeley.edu/snap/snap.html#present:Username=pavelbel&ProjectName=Bernat%20holes
I've changed scene size, ground (brick wall, 800x600) and hole sprites (as in my project) and added a timer to measure hole printing time. On my system it takes about 1.5 secs to make a sigle hole.
And here's my variant with the same sprites and sizes:
https://snap.berkeley.edu/snap/snap.html#present:Username=pavelbel&ProjectName=holes%20demo
(do not forget to press green flag before making holes)
It gives ~100-400 ms per hole on my system.
And it's no suprise because your algo searches through ALL the pixels of the ground sprite ("blitz map" block), while mine just loops over a relatively small array of opaque points of the "hole" sprite. And still it is slow enough (and strangely becomes slower and slower the more holes I make).
I'm sure it is quite possible to make these operations waaaay faster using "print on" logic that takes transparent pixels into account.