This is what I believe the situation to be. [`AbsoluteOptions`](http://reference.wolfram.com/language/ref/AbsoluteOptions.html) uses `FullAxes` under the hood. It turns out that `FullAxes` is still expecting [`Frame`](http://reference.wolfram.com/language/ref/Frame.html)/[`FrameLabel`](http://reference.wolfram.com/language/ref/FrameLabel.html) options to be specified using the old ``Frame -> {b, l, t, r}`` syntax instead of the new ``Frame->{{l, r}, {b, t}}`` syntax. This is why `FullAxes` issues messages and doesn't work. This means the solution is simply to fix these options before running [`AbsoluteOptions`](http://reference.wolfram.com/language/ref/AbsoluteOptions.html)/`FullAxes` on the graphic. Here is a method of doing so:

	System`Private`NewContextPath[{"System`"}];

	Begin["FullAxesDump`"];

	If[Quiet @ TrueQ @ Check[FullAxes @ ListPlot[{0,1000}],True],
		Unprotect[FullAxes];
		FullAxes[arg_] /; !TrueQ@$FACheck := Block[{$FACheck = True},
			FullAxes[fixOptions@arg]
		];
		Protect[FullAxes];

		fixOptions[x_]:=x;
		fixOptions[(tag:Graphics3D|Graphics)[g_, opts__]] := tag[
			g,
			Sequence @@ ReplaceAll[
				{opts, Frame->False, Axes->False},
				Rule[h:Frame|FrameTicks, rhs_] :> h -> fixRule[rhs]
			]
		];

		fixRule[{{l_, r_}, {b_, t_}}] := {b, l, t, r};
		fixRule[{d_, s_}] := {d, Automatic, s, Automatic};

		fixRule[rhs_] := rhs;
	]

	End[];

	System`Private`RestoreContextPath[];

Some comments:

1. I use ``System`Private`NewContextPath``/``System`Private`RestoreContextPath`` so that the variables inside of ``Begin["FullAxesDump`"]``/``End[]`` use the ``"FullAxesDump`"`` context instead of the ``"Global`"`` context. Without the context path switching code, the variables in the above cell get their contexts at parse time (when the cell is read into the kernel) and not after the [`Begin`](http://reference.wolfram.com/language/ref/Begin.html) statement is processed. An alternative is to make this a real package, but that seems too heavyweight for a simple bug fix.

2. I only redefine [`FullAxes`](http://reference.wolfram.com/language/ref/FullAxes.html) if using [`FullAxes`](http://reference.wolfram.com/language/ref/FullAxes.html) on a [`ListPlot`](http://reference.wolfram.com/language/ref/ListPlot.html) issues messages. This means that if you want to change the code after running it, you will need to first clear the new [`FullAxes`](http://reference.wolfram.com/language/ref/FullAxes.html) downvalue that is created by the code. Something along the lines of ``Unprotect[FullAxes]; Clear[FullAxes]; Protect[FullAxes];``

3. I use the ``foo /; ! TrueQ@flag := Block[{flag = True}, foo]`` trick so that the options get tweaked, and then the existing kernel code for foo gets run.

4. It turns out that ``Frame -> False`` needs to get explicitly added to the options so that [`FullAxes`](http://reference.wolfram.com/language/ref/FullAxes.html) realizes that there really isn't a [`Frame`](http://reference.wolfram.com/language/ref/Frame.html), and it must process the [`Ticks`](http://reference.wolfram.com/language/ref/Ticks.html)/[`Axes`](http://reference.wolfram.com/language/ref/Axes.html) code. Without ``Frame -> False``, the [`FullAxes`](http://reference.wolfram.com/language/ref/FullAxes.html) code turns ``Axes -> True`` into ``Axes -> {False, False}``. Note that options handling uses the first instance of an option, so adding the default (``Frame -> False``) at the end should not affect output.

I think that's enough explanation. Here is what happens after loading the above code:

	AbsoluteOptions[LogPlot[x^x, {x, 1, 5}, Frame -> True], FrameTicks];

	AbsoluteOptions[ReliefPlot[RandomReal[1, {10, 10}]]];

	AbsoluteOptions[ParametricPlot[r t, {r, 0, 5}, {t, 1, 2}]];

No error messages, although I don't claim that this fixes all cases where [`AbsoluteOptions`](http://reference.wolfram.com/language/ref/AbsoluteOptions.html) issues messages. A similar treatment is possible for [`FullGraphics`](http://reference.wolfram.com/language/ref/FullGraphics.html)