Yes, this looks useful and we can add it. I think I would prefer a more ugly name to make clear that this is dangerous stuff that can make your numbers odd.

Yeah. Maybe something like @unsafe_setfield / @unsafe_resetfield?

Yes these sound fine.

About implementation, I wonder if it would be better to do

struct FieldLens{field} end
function prop_to_field_lens(optic)
    ... # replace all occurences of PropertyLens by FieldLens
end

macro unsafe_setfield(ex)
    setmacro(prop_to_field_lens, ex, overwrite=false)
end

yeah that would make sense.

A relevant old PR with some discussion: #57. I agree such a functionality would be useful, and if others are fine with including the Expr(:new) internals hack, I also support it! :)

Also, it doesn't really need new macros IMO. Following the linked discussion, there are at least two ways to do it:

1. Just add FieldLens, then the syntax is @set y |> FieldLens(:x) = newx. This allows adding a FieldLens to a set call that uses properties otherwise, like @set y.x[1] |> FieldLens(:a) = newval.
2. No new functions/objects at all, use getfield(_, :a) (see support setting fields #57 implementation). It can either be type-unstable, or add a special getfield handling so that @set getfield($y, :x) = newx doesn't go to Base.Fix2.

Also, maybe setfield() from your first post should go to ConstructionBase.jl? It has setproperties() for example, that are used here.

Those alternatives sound kinda annoying to use. I'd rather scare users off by using a scary name rather than more awkward syntax.

Ofc these preferences are subjective, I just believe that "define a new macro" needs a much higher barrier than "define a new function/struct". Macros can do many nontrivial code transformations, while functions are much easier to reason about.
In this case, for a rare usage scenario, it just seems natural to reuse existing syntax IMO – rather than make everyone reading the code wonder what's this new macro (as it will be used much more rarely than @set).

Oh, and if adding field support in any capacity, then @set getfields(x) = (... newfields ...) should also be added and not forgotten :)
(getfields from ConstructionBase)

I agree with @aplavin's argument. How about just adding

struct UnsafeFieldLens{field} end

and the way to use it is:

@set obj[i].f |> UnsafeFieldLens(:myfield) = val

About getfield and getfields happy to have them if they respect the inner constructor. If we want bypassing versions of them, these also need scary names.

I tend to agree with you regarding the desire for "scary names" for such a functionality :) Is the Expr(:new) trick even officially documented anywhere?
If yes, if it was the official way to reliably set field values disregarding the constructor, then it could make sense do use as the @set getfield() backend IMO. But I don't think Julia documents it at all, meaning we should be very careful when exposing it to users.

Regarding the macro/struct syntax, I think I understand now what subconsciously worried me in the suggested macro. In Accessors, y = @set f(x) = v is designed to result in f(y) == v. Ideally, for any callable f(x): @set x.a.b.c, @set first(x.a).b, @set x |> PropertyLens(:a) – in all of these cases, the invariant holds. It also holds in the custom optics example in https://juliaobjects.github.io/Accessors.jl/dev/examples/custom_macros/.
@resetfield y.x = 5 reads like y.x == 5 afterwards, which isn't the case (it sets fields, not properties). Meanwhile, both @reset y |> FieldLens(:x) and @reset y |> getfield(_, :x) would follow that invariant.