Setting the context of a liquid variable can cause a namespace collision

I have a drop like this:

class FolderDrop < Liquid::Drop
  def initialize(folder)
    @folder = folder
  end

  delegate :name, to: :@folder

  def children
    @folder.component_instance.children.current.front_end.to_a
  end
end

I have a ComponentInstance drop that exposes a few methods like normal.

In the past, returning an array of ActiveRecord models that respond to to_liquid worked well. Liquid would call to_liquid on each in turn and we'd get the resulting liquid array with liquid objects.

This PR introduced the concept of calling context= on the item before calling to_liquid. This is confusing anyway since how do we know that this common method name isn't already being used? Shouldn't the attribute at least be namespaced (liquid_context)?

https://github.com/Shopify/liquid/pull/1781

In my case I have a column called context and coincidentally set it as a attr_readonly in Active Record. This caused a hard to debug LiquidError: internal so I ended up hacking my copy of liquid to raise the real error which was ReadonlyAttributeError on the column.

So I guess I have a few questions:

• Why doesn't Liquid allow the real error to be surfaced in a development environment (acknowledging that it's not just used in Rails)?
• Am I wrong in returning an array of values without calling to_liquid on them myself first?
• Is the solution to this to namespace the context attribute in liquid?

Start by reviewing Shopify/liquid#1781 and tracing how arrays of objects are handled through context= and to_liquid. Reproduce the namespace collision with a Liquid::Drop and an object exposing context, then determine the expected error handling and API behavior. Done means the questions have a documented decision and corresponding regression coverage.