I did some tests but I can't reproduce this inconsistent behavior that you are describing.

You can try for yourself here.

*I did some modifications to the shader based on what I think you are trying to achieve, but it works the same regardless of the modifications.

Here's what it looks like when previewing in Chrome:

I left a transparent border in two sides of the images (right and bottom) so it's easy to spot the differences with and without a border. You can see in the image that only the sides with a transparent border are rendered correctly.

Also added sine behaviors and a rotate to see what effects non round positions could have. It's possible to see some oscillation on the non-transparent borders of the circle, but nothing on the square.

Everything works consistently here, and adding other effects doesn't seem to extend the bounding box. Adding a transparent border or extending the texture through the xml solves the problem on my PC.

Are you getting the same results?

The artifacts are caused because your images "touch" the border of the texture, as you can see here:

So when sampling outside of the texture bounds, it samples the same border pixel (opaque) like if the texture repeated the border to infinity. This causes the glitches.

You can fix this by manually adding a 1px transparent border to your images or extending the effect bounding box in the shader xml.

Customizable editors should remain further down the priority list from good UI and UX.

I agree. In my opinion having three predefined options for light, medium lightness, and dark UI is all that's necessary. I was just using the customization as an example to my point.

But you can see what I'm trying to say here, right? Just don't allow C3 to become a bag full of special cases, exceptions and niche features (C2 is becoming more and more like that recently)

I understand, I share the same opinion about Construct being more versatile. I just don't see C2 as having too much niche features, it's in a good balance with easiness of use for me. And I don't think Ashley is particularly fond of the idea of making "a bag full of special cases" either.

Fimbul

I understand your opinion but as a designer I disagree with it. If you suggest make the editor support CSS instead of make the editor skinnable your not giving the real problem to Ashley solve, your are giving only one limiting solution. The end user needs a skinnable editor, if it's better to do it through CSS or other method is up to Ashley to decide based on all the other decisions he will need to do for the engine. If in the design path chosen by Ashley CSS ends up not being an option, then by your suggestion we will not have a skinnable editor, even though maybe there's other ways it could be implemented inside those restrictions.

So in my view there's no harm in asking requests that are not strictly architectural. Ashley can analyze what's needed to make that particular feature feasible and decide what is needed to change in the Construct architecture to make it happen. If Ashley is willing to make architectural changes...

Since this thread seems more serious in organizing things, I'll post my C3 feature suggestions here.

This is what I gathered over the years from using CC and C2. It includes only the main ideas that I remembered to take note. There's a lot of smaller things about use flow and UI that could be improved, but I think that listing all of them is not viable.

I don't know if everything complies with what the OP expects, so if needed be selective.

*The suggestions are loosely organized and in no particular order.

Rendering

• Textures independent from objects (reusable textures, preserve imported texture atlas)
• Multiple textures per object (color, normalmap, heightmap... accessible to shaders)
• Enhanced pixel compositor (access to world normalmap, depth buffer, heightmap... for post-process effects like 2.5D lighting (like Sprite Lamp), depth of field, ambient occlusion, fog... see Rayman Legends)
• Directly draw to layers as a primitive (built-in Canvas plugin functionality)
• Easier layer/object masking (auto duplicate objects/layers under the hood and apply proper blending mode to mask non sequential objects/layers, should only require what object/layer to use as a mask)
• Support for shaders with multiple passes (at least display as one in the IDE with all collected parameters)
• Define input-field's value transformation in the shader's XML file (like "x/255" or "x^2", so the user can work with more friendly numbers in the editor, without the need to include these in the shader code and waste resources recalculating for every pixel, the IDE/runtime could do this before passing values to shaders)

Behaviors

• Special interactive behavior stack for quick AI/auto-movement (steering behaviors rocks - seek, flee, wander, avoid obstacle, path/wall following, separation, alignment, flock, brake... - they add on top of each other, each have a weight slider that sets the degree of influence to the final movement, interactive with regular movement behaviors)
• Physics interactive with all movement behaviors (use verlet physics like Chipmunk as base that handles the set position problem)
• Support all physics features (prismatic joint, kinematic body...)

Event Sheet

• Functions as primitive with multiple return parameters (like it has for calling - allows to create contained functions that processes and returns multiple parameters without the need for parsing and using extra variables)
• Flexible data structures as primitives (list, arrays, dictionaries, trees, nodes... )
• Vectors for composite parameters (position, size, etc... with support for vector math, similar to GLSL: "sprite.position + vec2( cos(angle), sin(angle) ) * speed" - evaluates X and Y in a single expression )
• Local variables easily made global and vice-versa (set globals through a checkbox - not based on positioning, allows support for eventsheet-scope local variables, and to position globals anywhere for better organization, less unnecessary globals polluting var lists)
• Better handling of error and missing references (display events with broken references as red instead of hiding, even if references are invalid, but make them commented under the hood to not execute - allows to replace references later which facilitates migration of code between projects)
• Expressions automatically generated for each settable plugin/behavior parameter ("if one can set, one should get", being automatically generated ensures consistency always)
• "compare [property]" events being automatically generated for each expression (...or not exist at all: compare only through system compare, but it should be consistent)
• Manipulate SOL directly in eventsheet (save SOL to variable, pick by loading SOL, expression for SOLs intersection, expression for joining SOLs, expression for subtracting SOLs...)
• Pick objects by name / Get objects name

Interface

• Support for interface addons (third-party editors)
• Improved form controls for plugins/behaviors/effects (color picker, slider (or blender-like editbox), checkbox, bezier curve, display forms conditionally, forms grouping...)
• Improved blender-like editbox that favors value experimentation (demo here, works only on chrome and has some small bugs, but you can get the idea. The same features could be added to directly edit values in event-sheets)
• Editboxes support math operations during edit-time ("position.X: 100 * 2/3 + 10")
• Editboxes support expressions during edit-time ["position.X: round( sprite2.X ) + sin( sprite.angle )", pressing ENTER leaves the expression as a linked reference and SHIFT+ENTER evaluates it]
• Built-in visual data editors (for long text, arrays, nodes, etc...)
• Quicker event placing with improved wizard (filter lists in a single screen - no multiple wizard screens, auto-selects the last used actions when a new event is created, auto-casts the event selections when the object is changed, supports categories and folders filters, makes quick and easy to edit events - object, condition, parameter and expression selection in a single screen)
• In place events editing (similar to CC but better, use blender-like editbox features to edit values in place: drag to increment, ctrl to snap, shift to edit decimal...)
• Tags for event groups to reference them instead of the group name (separate organization name from functional tags, allows groups with same name for better organization, and to toggle multiple groups with same tags)
• Custom colors for events and actions (for better organization)
• Color coding for expressions based on the returned value type instead of segmented sub-attributes (clearer for reading complex expressions)
• Layers display all object instances contained in z-order when expanded (similar to Adobe Illustrator layers - improve the usefulness of the layers panel and eliminates the need for a specialized z-order panel, individual instances could be re-ordered and selected in this single panel)

Misc

• Group objects on layout editor (physical parenting, move and rotate all as a single entity, accessible in events... replacement for containers)
• Improved inheritance/family system (support mixed object types, sub-families, changing from object to family later is extremely inconvenient and should be re-thought, ...)
• Use fixed time-step for events and interpolated steps for display (game behaves more consistently across different devices and frame rates, solves the problem of missing collisions in low frame rates due to the discrete nature of Construct's collision test, increases the processing budget for events if run at e.g. ˜30 ticks per second, and lowers the barrier for beginners by eliminating the need for dt in events)
• Copy/paste/create instance variables from object (ability to transfer or clone instance variables from one object to another)
• Preview in layout editor (live preview)
• Multiple collision polygons per object (allow a different movement collision hitbox, from damage hitbox, from attack hitbox - could work like imagepoints, index 0 used as default by behaviors, and others accessible as a parameter of "is overlapping" or "on collision")
• Circle collision primitive besides polygon
• Different types of layers instead of some objects (2D layer, tilemap layer... possibility to be extended in future with 3D layer and vector layer - allows to display specialized toolbars depending on the selected layer, less cluttered than using objects, easier to manage and edit)
• Merge sprite and tiled-background ("tilling" as a property of sprite)
• Sprite distortion (similar to CC mesh)
• Set anchor point for tiled-background (set if the texture is anchored horizontally to the left/center/right and vertically to the top/center/bottom - determines to what sides the texture expands)
• Object's scale detached from width and height (like the editbox demo *works only in Chrome, "obj.finalSize = obj.size * obj.scale", where obj.scale is an arbitrary value defined by the user and not derived from obj.size - more intuitive than current method, solves the obj.scale expression problem)

I have made a motion blur effect for my own use a long time ago that is pretty much like your request.

It still needs some cleaning up and polishing to be published for public though. Whenever I find the time I'll try to work on it and release to the community.

I have a dozen other effects on the same situation, but I lack the time or drive to polish and optimize them.

Someday I'll get to it!